@
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的关注，祝好。