云服务OpenAPI的7大挑战，架构师如何应对？

确定了设计模式和资源模型后，是时候进入到API设计细节了。诸如API名称、参数名、属性名称、数据格式、错误码之类的信息，看起来根本不是问题。单个产品问题还不大，只要保证内部风格一致即可，如果考虑到云服务多产品对外的整体体验，就有必要考虑以下问题：

• 在API命名的时候，遵循什么样的范式来确保大体风格相似?动词、名词、介词如何组合才能保持API风格看起来比较统一，降低理解成本?
• 对于类似的操作，有没有使用规范?有哪些公共的标准词汇使得同类型的操作可以比较容易理解，避免使用晦涩奇怪的词汇(例如读操作，Read/Query/Describe/List/Get中都在什么场合使用什么动词)?
• 被广泛使用的参数如何尽可能保持一致，避免不同产品的表达混乱的情况(例如分页参数用PageNumber还是PageNum)?
• 对于常用的场景，例如幂等、分页、异步API的设计有没有统一的规范，避免使用体验不一致?
• 错误码应该怎么设计?公共错误码怎么统一，业务错误码怎么表达?

上述问题都是实际研发过程中要注意的，要全部罗列的话远不止这些。API的用词描述是云服务展现给外部用户的第一印象，绝非随意写就。对人员有一定规模，内部有多条产品线的组织来说，如何协调组织的各个部分对外具有统一的体验是个很大挑战。

回顾下HTTP协议，最广为认知的是对HTTP Mehod的约定，使用9个单词就完成了对基本动作的规范，为开发者提供了清晰的思维模型：

Http Method 类型

图片来源：https://tools.ietf.org/html/rfc7231

同样，在HTTP Header里面也对浏览器信息、语言、网络连接属性等做了详细的规定，这样开发者在使用HTTP服务的时候都有一个大致的约定，在关键信息上面不会有偏差，保障了异构系统的接口一致性。

因此云服务在管理API时应该考虑一些具体的规范，对命名规则、标准词汇、最佳实践模式、错误码等信息都有明确的规定，同时用系统化、平台化的手段来管理API，确保不走偏。设计风格不是云服务API设计中致命的问题，但是它关乎云服务外表形象，不可不察。

挑战4：服务端容错处理

API是后端服务的外部表达，是服务就有可能出现问题，无论这个问题是可预期的还是不可预期的。如果只考虑功能本身功能特性，而忽视对异常情况的设计，当问题出现的时候业务本身可能无法感知造成服务异常，更重要的是站在客户角度去看，不能有效获取错误原因是非常痛苦的，很多时候只能束手无策，降低云服务提供商的整体口碑，甚至损害营收。

假设有个创建资源的API，每调用一次都会创建新的资源，考虑以下情况：

• 同样的请求多次提交，是否会重复创建资源?
• 请求处理时间过长，客户端是长时间等待，还是先异步返回一个任务ID?
• 如果需要等待，Timeout最大值是多少?
• 如果Timeout最大值达到，客户端的策略是重试还是放弃
• 如果最终处理还是失败了，具体是哪个环节的问题?如何给出准确的错误信息?
• 如果异步方式，异步处理完成后是主动查询还是另有通知?
• 第三方工具和集成商到哪里去获取这些信息?能不能有标准化的处理?

（编辑：PHP编程网 - 湛江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!