我有一个通过http运行的Soap服务。这也是REST服务吗？使其成为REST服务的标准是什么？最终将其排除为REST服务的标准是什么？有些帖子（例如here）比较了REST和Soap，但似乎并没有直接回答这个问题。我的回答是：是的，Soap服务在其功能级别上是一个http请求，该请求返回XML有效负载，其中服务器不维护状态，因此是REST服务。
答案 0 :(得分：2)
Fielding在他的dissertation中说：
REST提供了一组体系结构约束，当整体应用时，它们会强调组件交互的可伸缩性，接口的通用性，组件的独立部署以及中间组件，以减少交互延迟，增强安全性并封装旧系统。 / p>
如果将上述属性与Web浏览进行比较，您会发现两者之间有很多相似之处，因为Fielding只是采用了使Web如此成功并将其应用到更广泛领域的概念，这也应允许应用来“上网”。
为了正确地调用体系结构REST，它必须支持自描述性，可伸缩性和可缓存性，同时还必须遵守并遵守底层传输协议概述的规则和语义，并强制使用定义明确的标准，例如媒体类型，链接关系名称，HTTP操作，URI标准，...
HATEOAS利用服务的自我描述性（或者说仇恨，正如我倾向于说的那样，因为像我这样的人，看到REST的好处总是必须强调这个关键术语，因此最终也是如此）以自己的meme）。通过HATEOAS，服务器为客户端提供客户端可以从客户端所处的当前“状态”中采取的所有可用“操作”。此处的“操作”只是具有客户端可以关联的链接关系名称的链接。用于推断何时最佳调用该URI。返回响应的媒体类型可以定义如何处理此类链接。 HTML，即指出，点击链接后，会触发GET请求，并且链接的内容会加载到当前窗格或新标签中，具体取决于链接所具有的参数。其他媒体类型可能会定义相似或完全不同的内容。但是，这里的总座右铭是：继续探索。因此，最好将REST体系结构中的交互模型设计为affordance and state machine，而实际服务应更像网站方法，其中服务器在教导客户端，即关于请求的外观和发送方向请求（类似于HTML表单）。
由于大量的Web或多或少是静态的，并且大多数请求都集中在检索上，因此Web严重依赖于缓存。通常，REST API也希望达到同样的效果，因此对可缓存性的要求很高，因为如果适当地进行缓存，这可以显着减少服务器上的工作量。
通过使客户端状态远离服务器，这还允许将服务的新副本添加到位于负载均衡器或新区域后面的新服务器上，从而提高可伸缩性。客户端通常不在乎从何处检索数据，因此服务器可能只返回指向克隆而不是自身的URI。
另一方面，SOAP是RPC，例如Java的远程方法调用（RMI）或CORBA，您在其中拥有自己的接口定义语言（IDL）来为您生成客户端存根代码，其中包含有关如何实现的实际逻辑。将某些对象转换为字节流，以及如何在调用某些方法的情况下通过导线发送它们。
SOAP违反REST约束的地方显然是由于缺少caching support以及实际使用客户端之前需要具备的带外知识。 SOAP消息通常总是以POST操作的形式交换，默认情况下是不可缓存的。某些HTTP标头可用于允许中间服务器缓存响应，尽管SOAP没有使用它，因此缺乏对它的一般支持。
为SOAP端点A开发的客户端很可能也无法与其他公司运行的其他SOAP端点B互操作。尽管可能有人争辩说Web客户端也不知道如何处理每种不同的媒体类型，但浏览器通常提供插件机制以将这种知识加载到客户端中。除了已标准化的媒体类型外，它至少应该是媒体类型，因此可以在大量服务器上使用（请考虑使用Flash支持）。 SOAP服务还有另一个问题，就是在WSDL定义中进行了任何更改之后，不知道更新的客户机很可能会停止使用该更新的服务，直到客户机代码被更新为可与生成的存根类的最新版本一起使用为止。
关于在SOAP中交换的XML格式：尽管从技术上来说，REST服务可以返回SOAP XML有效负载，但该格式本身缺乏HATEOAS的支持，这是必须的，而不是一种选择。客户端应该如何仅根据接收到的响应，而不对API本身有任何先验知识，根据接收到的响应做出进一步选择？
我希望您能看到SOAP缺乏缓存支持，可能存在可伸缩性问题，并导致客户端与实际API紧密耦合。 SOAP消息envelop / header / body缺少HATEOAS支持，这也不允许客户端自由浏览API，从而自动适应服务器更改。
答案 1 :(得分：1)
正确的REST服务遵循Roy Fielding论文的chapter five中阐明的体系结构准则。当大多数人真正表示“ HTTP API”时，会错误地使用术语“ REST API”。无状态状态是API遵守REST体系结构准则的必要但不充分的条件。
