写了一个青云 Qingcloud PHP SDK，支持目前官方所有 API 接口。

[suriv520]

官方除了一个完成度不太高的Python SDK，N久没有其它语言的SDK了，看来是难产了。。。

https://github.com/fangli/qingcloud_php_sdk

完全按照官方说明文档编写，支持官方所有的API接口，人性化调用。需要php curl扩展。单class文件。

（从官方目前的公开文档来看，这个SDK完成度是非常高的。但*众所周知*，Qingcloud不排除以后会有第二版的API、除了IaaS之外的服务等等，其API接口本身也处在变化中没有完全稳定，所以嘛，先用着。官方API没有完全稳定的情况下，SDK做得再完善也白搭……）

嗯哼，想拍砖请随意Issue或者Pull requests，不拍砖请送星星～～～～

[walnutzhang]

先代表 QingCloud 谢谢你！
关于API的问题，可以放心，以后的API也是会兼容的，不必过于担心以后API改进的问题。你这个SDK以后也可以逐步完善。
Github上也已经有一些用户自己开发的其他语言版本的SDK，有需要也可以先看一下他们的实现。

API使用过程中有任何问题欢迎通过工单和我们联系反馈。

再次感谢 :-)

[suriv520]

@walnutzhang 谢谢回复。

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

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

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

[sunight]

@suriv520 是的，

[sunight]

@suriv520 当前 API 中有个公共参数 version，以后如果有难以兼容的 API 改动，我们会通过这个参数维护多个版本。

刚才看了下，目前这个 sdk 是这么实现的：
$qc1->StartInstances(array('instances.1' => 'i-xxxxxxxx'))

如果能改为
$qc1->StartInstances(array('i-xxxxxxxx', 'i-yyyyyyy'))

使用起来会不会更方便？当然，我对 php 没有你熟悉，仅是一个小建议：）

[suriv520]

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

[sunight]

aws 的 API 也是类似吧，method 都是 GET，参数也是

[sunight]

[为啥v2ex总是莫名就提交了。。两次了。。]
接上面，参数也是类似的 ****.n(n>0)，如：
https://ec2.amazonaws.com/?Action=StartInstances
&InstanceId.1=i-10a64379
&AUTHPARAMS

超出GET请求长度的情况很少见，正常使用一般不会遇到。
虽然HTTP API 的参数用起来不是很方便（受限于GET请求，但也谈不上麻烦嘛），不过 SDK 可以简单封装一下，让传参更便捷。
我们也喜欢json，返回json格式也是觉得开发人员处理起来比xml更方便，不过如果直接把json字符串作为参数还是略显混乱。

[XXOO]

云计算，流量都没按量使用的方式，我只能呵呵。

[sunight]

@XXOO 别急，正在开发中，即将上线。

[XXOO]

@sunight 好吧。期待加入云盾一样的吧，天朝太多恶意的攻击了。Ddos让人很犯

[sunight]

@XXOO 是的，WAF 也在设计阶段，预计年底提供。

[XXOO]

@sunight 哎再这方面（按量计费，云盾）路后x云5年，不过ssd方面领先x云。

[sunight]

@XXOO x云起步早嘛，aws更早，一步一步来，都会有的。只要关键的地方做的绝对出色就行了。
对了，我们还没用到 SSD 呢，已在准备方案，到时磁盘性能还会有很大提升。

[oott123]

刚刚在 GitHub 上看了看，楼主的这个 SDK 居然是 GPL 开源的……
有点心碎……

[chousb]

我小弟最近写了一个版本： https://github.com/yunify/qingstor-sdk-php