api如何使用_比较REST和SOAP: 如何为你的项目选择一款正确类型的API？

众所周知，构建API的一个最大的挑战是如何设计并实现一个稳定和可持续使用的API。对于基于HTTP的Web API更是如此。不稳定的，经常需要更换数据格式的API往往会给API开发者，以及API的使用者造成不小的麻烦。

一个稳定的API应该建议起自己和用户之间的编程契约，也就是服务器与客户机之间的数据契约。对于Web API而言，这个契约通常应该使用XML Schema或者JSON Schema规范来表达。

虽然我们很容易理解API的含义及其功能，但是在选择构建哪种类型的API，理解为什么这种类型的API最适合你的应用程序，然后将其设计成有效产品，确保开发人员长时间去使用它，-因此，挑选的API类型显得格外重要。

当前，目前存在很多类型的API，例如Web API就是其中最常见的API类型之一，这类API也被称为Web服务，主要为Web应用程序或需要经过网络连接通信的应用程序提供接口。这样的公共API有成千上万，从检查交通和天气，到更新社交媒体状态，线上支付等等。除了公共API，还有成千上万的私有Web API，一般的公众没有权限使用这些API，相反的是，它们一般被公司用以扩展服务和相关功能，进一步扩大了应用范围。

另外，还有一些其他类型的Web API，比如简单对象访问协议(Simple Object Access Protocol, SOAP)、远程过程调用(Remote Procedure Call, RPC)，也许还有最流行的（至少是在名称上）REST API。随着REST和RESTful APIs变流行起来，接下来我们将详细介绍SOAP和REST之间的区别，以及这些API的最佳用途。

如何比较SOAP和REST API？

让人遗憾的是，虽然目前绝大多数的手机应用程序都是通过API与服务器进行交互，但围绕REST API的概念还存在很多误解和混淆之处。以致于大多数开发者认为自己在设计构建，并使用REST API，但他们实际上是在使用某种形式的HTTP API。

以下内容节选自Stackoverflow的高分答案：SOAP vs REST (differences)，以帮助大家理解什么是REST以及REST与SOAP的关键差异：

1) REST是独立于协议的，它不与HTTP进行耦合。就像你可以在网站上使用ftp链接一样，REST应用程序可以使用任何具有标准化URI方案的协议。

2) 大多数REST API的开发者使用HTTP提供的几种方法来描述CRUD。但REST其实并不是CRUD操作到HTTP方法的映射。

3) REST与你正在使用的部件一样都是标准化的。 其中HTTP的安全性和身份验证也是标准化的，因此这是你在通过HTTP进行REST时使用的内容。

4) 没有超媒体和HATEOAS，REST就不是真正意义上的REST，这也就意味着在REST API设计理念中，客户端只需要知道Web服务的入口URI资源，从服务器返回客户端的数据中应该包含进一步访问更多资源的超连接。如果遵循严格的REST API来实现，客户端将被紧紧绑定到某个API的特定版本上，同时必须为API版本的更改做出更改，否则就很可能会发生崩溃。

5) REST本身是模拟Web资源模型的API设计风格。设想当某个用户进入一个网站寻找某个问题的答案时，用户知道什么是问题，什么是答案，并且网站会为你提供了指向这些信息的链接。REST API也必须执行相似的操作。如果按照通常人们对REST的理解去设计Web，那么我们将会需要一份线下的文档来向用户解释：必须采用类似于：

stackoverflow.com/questions/<id>

这样的方法去寻找问题，然后用Question.id替换<id>并将其粘贴到浏览器上以得到问题的答案。这其实是对REST的一种误解，但这就是很多人所理解的REST的含义。

6) SOAP的设计更接近于远程过程调用（RPC）：客户端和服务器通过一个严格的契约来请求和交换数据。对于HTTP，SOAP规定向一个固定的URL POST XML数据，并从请求的响应中获取XML数据，这样的设计相比REST更贴近于API调用这个场景。也更容易理解。

7) SOAP和REST本质上应该说是无法直接进行比较的，因为SOAP是一种数据交换协议，REST是一种架构风格。也许是因为人们倾向于将任何非SOAP的HTTP API称为REST，才导致两者的信息产生混淆。

需要强调的一点是，如果客户端是通过API文档来编程并发起请求和获取数据，而不是在请求URL后，从得到的数据中获取超文本链接，那么这一定不是REST。 REST的作者Roy Fielding曾经明确表示过：REST必须是超文本驱动的。

最后，大多数使用HTTP API的开发者错误地将其称为REST API，并声称这很好地解决了他们的问题。但他们从来没有超出这个范围，使用到REST API的资源驱动模型和HATEOAS等特性。这也就很好的证明了REST其实并不适合所有人。对于开发者来说，真实的REST风格有时候反而将会很难设计和使用维护。

通常情况下，我们认为SOAP，或者思想近似的JSON API具有更好的抽象，更贴近于“API”这个概念。在项目开发中，我们不应拘泥于某种例如API的风格，例如REST，而是结合自身的实际需要，通过JSON Schema等手段来为自己的API添加风格清晰的契约，帮助更好地完成目标。