Amy Palamountain 在最近的新西兰技术大会上进行演讲时透露,当我们开始为自己的业务构建一个新的 Web API 的时候,我们想要构建一个相当优秀的 API,在 Internet 上答案就是构建一个 REST 风格的 API。
那么 REST 风格的 API 对于你的问题始终都是最佳解决方案么?Amy 认为这依赖于它的上下文,但是对于公共 API 她的经验是,应该使用 REST 风格并且要基于 HTTP 和 Web 的核心理念构建。
SOAP 和其他的 RPC (远程过程调用)API 与两种执行上下文有关,分别是客户端上的和服务器上的上下文,这种情况下客户端需要远程调用服务器上的一个操作。这是一种以操作为中心的设计,需要预先确定一种协议,但是这样客户端和服务器就紧耦合了。Amy 认为对于公共 API 而言这是不合适的,因为缺乏可用性和灵活性,例如如果服务器上发生了变化那么客户端就很有可能会无法工作。
Amy 认为从 RPC 风格中解脱出来的第一步是将操作转移到暴露领域概念的资源中,例如实体。这种移动的另一部分是拥抱 HTTP 和 URI,通过实现和 HTTP 规范更加一致的 API 增强它们的可用性并使其更加容易使用。
但是如何使用内置到客户端中的 API 依然有一些固有的问题,资源之间的关系变化依然会破坏客户端并且需要重新部署。
Amy 策略的第二步是添加超媒体,使用链接(Links)显示资源是如何关联的。在一个 Web API 中使用链接确保包含所有需要的信息,没有带外的信息。超媒体解决了固有的问题,因此应该在客户端内部:
- 链接显示资源之间是如何关联的
- 链接显示如何与问题空间交互,以及下一个可能的操作
- 链接能够根据发展情况动态地对问题空间中的选项进行增加和移除
但是有一些实际的问题需要考虑,特别是在客户端上。超媒体 API 需要超媒体驱动的客户端,客户端必须理解服务器使用的媒体类型。媒体类型描述了链接和表单等内容的语义含义。
在她的呈现中,Amy 使用了一个带有一个服务器和两个客户端的示例,一个使用资源和 URI,另一个使用超媒体,这两个都使用了 ASP.NET Web API 框架通过 C#语言编写。
评论