对于php这种不需要直接面向最终用户分发的程序，其实GPL没什么限制哈～～即使做商业使用，跑在自己服务器上，做任何修改，也是不需要开源的～
哪天等青云的api稳定了，我继续做个上层封装，加上对PSR-4与Composer的支持，以BSD或MIT发布也可以。
P.S.
https://github.com/fangli/qingcloud_php_sdk

这个想做到靠谱且稳妥，除了把polling模型改为push模型，没有更好的办法。

但据我推测你们的应用场景，可否尝试考虑“当最终用户请求时向后段API发起查询”？虽然效率慢点，但比长年DDOS空跑要好。

但如果你们确实是需要实时的数据的话，并且也没办法让上级API提供回调的话，或者也没有批量接口的话，只能跟踪每一个订单的源和目的，综合分析历史数据，建立模型。并且实时根据每次获取到的信息，推断并建立当前delivering状态的所有包裹的“批次”数据（这里的批次是指在同一个运输工具里的所有包裹）。

这个批次与分发模型建立起来后，你的系统里应该已经有整个邮局的运输网与运输效率数据了，进阶一点的，可以离散分析周期性的数据，甚至连航班、陆运的班次与起讫时间你都可以了解得一清二楚。

这些建立起来后，你问我怎么获取最新数据？随便把预测的同一个批次的货物里挑选5%或者10%进行API查询，如果有新数据超过一定阈值，说明到货了,再一窝蜂地把关联数据全部调用一次API最终确认。

这是bigdata的基本思维，从混沌（每个包裹）中抽象出上层的关联（批次、运输等），再从上层整体的关联，预测离散的行为，甚至是未来的趋势。

这是学院派的方案。脑洞大开供，纯理论讨论，欢迎拍砖。

真正兴奋的人现在正在补觉呢。

@HiVPS 问下大概需要多长时间才能拿到证书？几十分钟？几个小时？几天？

已经来了一个了

跟了两次PD升级，再也不入这个坑了。
MacUpdate网站喜大普奔地给了PD一颗半星的评价……

This is like you just got a car and one years later you car company tells you that you have to upgrade your car's system at 60% of total purchasing price, otherwise your car will be no longer compatible with current roads and traffic lights, gasolines, all the agreement and insurances you'd purchased are expired now.

@sunight
@walnutzhang
我仔细研究过你们的API文档与接口，坦诚地讲，有些设计实在谈不上『优雅』。

就如你举的例子来说，
你们文档里的描述就是"instances.n"，其中n是从1开始的数字，你们对此的设计赋予的期望就是『一个以instances为key的dict，其值为一个list』，既然如此，为什么不直接用JSON？为什么不直接从0开始？

从API返回的JSON来看，你们在尝试将Request的JSON平面化，但显然，JSON可以有无限多层，而按照API v1，Request能描述出来的结构应该只有两层。否则，多层参数会变成类似『instances.1.interface.2.addr』的扁平key。(是不是要多丑有多丑？）

另外，大多数语言，都能够充分且完整（原生）支持JSON的解析，像Nodejs、Python(Dict/List)、PHP(Associate array)、Ruby(hash/array)之类的语言，基本上内部数据对象就能与JSON一一对应，并且无缝转换。

另外，APIv1的整个请求，是HTTP GET。需要提醒的是，URL的参数在长度上是有限制与标准争议的～如果我构造了一个超级长的列表，那么这个Request本身可能是『不合规范』的。（当然，能不能正常处理另当别论，参考 http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers ）。即使你们的API server能够正常处理，你们也不能保证Proxy server能正常处理……

所以，在实现SDK的时候，其实我是非常纠结的，究竟要不要对你们这个.n的设计进行list->.n的解析与转换。

其实，以我个人(devops)观点来看，这里的API最好的设计其实不需要『设计』：
POST /iaas/xxxxxx
Content-Type: application/json

{
"instances":[
{"instanceid": "i-xxxxxx", "other-attrib": "other-value"},
{"instanceid": "i-xxxxxx", "other-attrib": "other-value"},
],
"xxxxx": {"xxxxx"},
}

上面这些，也是让开发者觉得这个v1的API『没有那么reliable』的原因之一吧。

其实可以参考一下AWS的API设计，他们的API spec给人的印象是非常健壮、无歧义且可靠的。

另感谢Qingcloud的关注，祝好。

@walnutzhang 谢谢回复。

既然已经表态API的稳定性了，那我就可以把:

1. 当前API版本
2. Iaas命名空间

这两块都加到SDK里去了。以后既可以直接兼容新版本的API，也可以调用非IaaS的接口。为升级做准备。
按照官方的说明，主要的API扩展就在这两个方向，对吗？

啊，开源了啊……看来我可以自己动手丰衣足食的……

另外，强烈建议增加一个transparency的选项。
你截图的几副背景倒还比较『素雅』，看起来效果不错，但实际上70%随机的背景都『凌乱且不适合做背景』。如果有个transparency的选项的话，就可以把所有的图都变得『淡淡的』，看起来不那么触目惊心……

......说得有点多，纯粹个人感受，并不是挑刺。谢谢你的作品。

或者如果后台下载技术难以实现，也可以先显示一个纯白色的背景，任何元素都hide起来，然后在图片加载完成后再fade in。

支持一个！界面做得有设计感，简约不简单。
另有个小建议提一下：每次new(tab)时，明显感觉图片从上到下加载，有时候还会略卡一下，非常影响感受！可否在后台多下载并缓存几幅图，然后new(tab)时，做一个fade in的缓冲效果？

从Windows换到Mac时，发现CMD好不习惯啊。但瞬间就适应了。
从Mac换到Windows时，发现Ctl太难按了。再也习惯不回去了。