本文主要讨论了云服务的API设计的重要性以及一个关于天翼云查询云主机云硬盘列表API的实例。作者指出云服务中的API设计不能轻易改动,错误的设计会带来长期的影响。文章还以一个天翼云的API为例,说明了即使在API兼容性要求下,错误的参数名仍然需要被保留,即使已逐渐不被推荐使用。
文章强调在云服务领域,API的设计至关重要,一旦设计错误,后果将长期存在,影响公司的声誉和客户的使用体验。
文章以一个具体的实例——天翼云的查询云主机云硬盘列表API,说明了API设计不当带来的问题,如参数名错误、需要保留荒谬可笑的参数等。
文章指出,由于API兼容性要求,即使已知参数存在错误或逐渐不被推荐使用,只要仍有客户使用,服务商就不得不继续保留这些参数。
文章提醒云从业者,在API设计中应避免交给实习生随便设计,强调专业性和严谨性。
有些朋友很喜欢写脏代码,”先上线再说,以后再改”,他们这样说。
对于大多数互联网应用的代码,确实如此,无非就是增加些版本管理的负担。
但是云服务不一样,API 尤其不一样,基本改不动。如果你设计错了,这个耻辱会跟随你很多年,并且一直公开展示,供大家嘲笑。
有读者投稿一个行业耻辱柱,大家可以看一下天翼云的查询云主机的云硬盘列表 API
https://www.ctyun.cn/document/10026730/10596897
懒得打开链接的可以看我截的图
显然,dickid 是个很初级的错误,天翼云也修正为diskid了。但是由于 API 兼容性要求,天翼云不得不保留这个荒谬可笑的鸡鸡 id 参数。
两年多过去了,天翼云还只能跪求客户:
云硬盘ID,推荐使用diskID,该字段将在后续进行逐步下线处理
dickID | String | 云硬盘ID,推荐使用diskID,该字段将在后续进行逐步下线处理 | 70a3768d-386e-416c-8abc-fc467e67432c | |
diskID | String | 云硬盘ID
|
只要有一个客户还在用这个版本的 API,天翼云就没办法下线这个参数,就只能自己把这个耻辱挂出来,供大家嘲笑。
各位云从业者,API 设计,别交给实习生随便乱搞了