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#语言编写。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论