1
walnutzhang 2014-09-01 13:53:56 +08:00 1
先代表 QingCloud 谢谢你!
关于API的问题,可以放心,以后的API也是会兼容的,不必过于担心以后API改进的问题。你这个SDK以后也可以逐步完善。 Github上也已经有一些用户自己开发的其他语言版本的SDK,有需要也可以先看一下他们的实现。 API使用过程中有任何问题欢迎通过工单和我们联系反馈。 再次感谢 :-) |
2
suriv520 OP @walnutzhang 谢谢回复。
既然已经表态API的稳定性了,那我就可以把: 1. 当前API版本 2. Iaas命名空间 这两块都加到SDK里去了。以后既可以直接兼容新版本的API,也可以调用非IaaS的接口。为升级做准备。 按照官方的说明,主要的API扩展就在这两个方向,对吗? |
4
sunight 2014-09-01 15:04:56 +08:00
@suriv520 当前 API 中有个公共参数 version,以后如果有难以兼容的 API 改动,我们会通过这个参数维护多个版本。
刚才看了下,目前这个 sdk 是这么实现的: $qc1->StartInstances(array('instances.1' => 'i-xxxxxxxx')) 如果能改为 $qc1->StartInstances(array('i-xxxxxxxx', 'i-yyyyyyy')) 使用起来会不会更方便?当然,我对 php 没有你熟悉,仅是一个小建议:) |
5
suriv520 OP @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的关注,祝好。 |
6
sunight 2014-09-01 17:21:27 +08:00
aws 的 API 也是类似吧,method 都是 GET,参数也是
|
7
sunight 2014-09-01 17:29:44 +08:00
[为啥v2ex总是莫名就提交了。。两次了。。]
接上面,参数也是类似的 ****.n(n>0),如: https://ec2.amazonaws.com/?Action=StartInstances &InstanceId.1=i-10a64379 &AUTHPARAMS 超出GET请求长度的情况很少见,正常使用一般不会遇到。 虽然HTTP API 的参数用起来不是很方便(受限于GET请求,但也谈不上麻烦嘛),不过 SDK 可以简单封装一下,让传参更便捷。 我们也喜欢json,返回json格式也是觉得开发人员处理起来比xml更方便,不过如果直接把json字符串作为参数还是略显混乱。 |
8
XXOO 2014-09-01 17:41:48 +08:00
云计算,流量都没按量使用的方式,我只能呵呵。
|
13
sunight 2014-09-01 22:33:44 +08:00
@XXOO x云起步早嘛,aws更早,一步一步来,都会有的。只要关键的地方做的绝对出色就行了。
对了,我们还没用到 SSD 呢,已在准备方案,到时磁盘性能还会有很大提升。 |
14
oott123 2015-02-12 10:22:17 +08:00
刚刚在 GitHub 上看了看,楼主的这个 SDK 居然是 GPL 开源的……
有点心碎…… |
15
chousb 2016-12-14 16:17:00 +08:00
我小弟最近写了一个版本: https://github.com/yunify/qingstor-sdk-php
|