首先，云服务开放的是基础设施和服务接口，一般是系统级的对接，API一旦开放想要变更就非常困难；
其次，云服务并非单独运行，不同的产品实际场景中是互相组合的，需考虑产品间的一致性和互通便利性；
云服务API数量庞大，为了更方便使用，配套的API查找、编排、自动化生成SDK等需求也比普通服务强烈；
云服务的稳定性非常重要，核心产品的稳定性就是客户的生命线，要求非常高。
选择支持哪种风格，才能更好地体现业务特性，让客户操作起来更加方便；
设计API时能否面向资源设计，相应的工程人员是否具备做这种设计的能力；
针对这种风格工具链的支持是否到位，投入产出比如何；
业界流行的趋势如何，是否需要考虑与其他系统体系的互操作。
Image caption
它可以使API具有更清晰的结构，帮助用户理解；
它可以帮助对比API与后台实体关系模型，更容易提供更完整的API服务；
它可以使产品协作更加顺畅，对资源的操作也更加规范化；
它可以使云服务底层平台实现起来更统一、更方便；
它可以使围绕API的生态集成起来更加简单、高效。
在API命名的时候，遵循什么样的范式来确保大体风格相似？动词、名词、介词如何组合才能保持API风格看起来比较统一，降低理解成本？
对于类似的操作，有没有使用规范？有哪些公共的标准词汇使得同类型的操作可以比较容易理解，避免使用晦涩奇怪的词汇（例如读操作，Read/Query/Describe/List/Get中都在什么场合使用什么动词）？
被广泛使用的参数如何尽可能保持一致，避免不同产品的表达混乱的情况（例如分页参数用PageNumber还是PageNum）？
对于常用的场景，例如幂等、分页、异步API的设计有没有统一的规范，避免使用体验不一致？
错误码应该怎么设计？公共错误码怎么统一，业务错误码怎么表达？
同样的请求多次提交，是否会重复创建资源？ 请求处理时间过长，客户端是长时间等待，还是先异步返回一个任务ID？ 如果需要等待，Timeout最大值是多少？ 如果Timeout最大值达到，客户端的策略是重试还是放弃 如果最终处理还是失败了，具体是哪个环节的问题？如何给出准确的错误信息？ 如果异步方式，异步处理完成后是主动查询还是另有通知？ 第三方工具和集成商到哪里去获取这些信息？能不能有标准化的处理？
云服务API直接面向用户，由于调用量大，变更影响的用户范围也更广，版本变更要非常谨慎；
云服务有多种形态，主要是公有云、私有云、细分的行业云等，不同的云对同样功能API的要求可能不一样，API更加多样化。既要保障不同版本功能正常，又要能快速部署维护不同版本，挑战很大；
不兼容变更的推广极其困难，很难让用户在短时间内快速升级，维护多版本API成本很高；
必须变更的情况，要确保调用方能够及时感知并且平滑切换的技术难度很大。
API刚刚上线尚未打磨充分，贸然开放可能会留下隐患，再想调整为时已晚，所以选择先不开放。
API本身并非原子化，封装了若干业务场景，主要目的是优化性能或者服务特定的客户，并不需要开放给所有用户；而且当业务场景发生变化的时候，调整起来也比较困难，不适合开放出去。
某些API不适合开放给全部用户，只能部分开放，例如特定行业专业的API。
API仅供特定场景或私有场景使用，需要外部能够访问，但是不能开放给用户。
