为什么不是SOAP

 

我了解RESTful是一种架构风格，但究竟是什么让基于SOAP的Web服务不能算作RESTful呢？

我不清楚下面哪些点（来自维基百科），不符合SOAP。

  • 客户端服务器
  • 无状态
  • 可缓存
  • 分层系统
  • 按需代码（可选）
  • 统一的界面
  • 资源识别
  • 通过这些表示操作资源
  • 自我描述的信息
  • 超媒体作为应用程序状态的引擎

    • 编辑 ：我刚刚遇到这个总结它很好。

    REST不是RPC，RPC说，“定义一些做某事的方法”，而REST说，“定义一些资源，他们将有这些方法”。 这是一个微妙而重要的区别，当给定一个URI时，任何人都知道他们可以通过预定义的方法与它进行交互，并接收标准的HTTP响应。 所以给定http://www.peej.co.uk/我知道我可以发出一个GET并接收一些有意义的东西。 然后，我可能会尝试使用PUT来更改它并接收有意义的HTTP错误代码，因为我没有被授权干涉它。

    SOAP遵循RPC模式。 SOAP API描述了一系列方法，以及它们的参数和返回值，您可以从代码中调用它们。 有一个编组步骤将其转换为网络表示形式。

    REST从来不是RPC。 REST API描述了一系列资源，以及一组能够对它们起作用的动词（通常是HTTP的GET，POST，PUT，DELETE）。

    要直接回答您的问题：SOAP主要违反了第6点（它不提供跨API的一组统一的动词）。 它也违反了第2点（服务器可以维护每个客户端的状态），结果也是第3点（状态阻止缓存）。

    REST和SOAP不是等价的概念。

    休息：

  • 取决于一个传输协议（HTTP）。
  • 充分利用该协议的特定功能（动词GET，POST，PUT，DELETE，缓存，标题和预定义的错误代码）。
  • 没有任何关于来回传递的信息的格式。 但是，由于HTTP谓词和URL已经定义了要采取的操作，因此消息正文只能包含数据。
  • 消息安全性由传输协议（HTTPS）提供，并且仅为点对点。 如果你想要保证消息的端到端，你必须自己做。
  • 最初用于简单的对象上的CRUD操作。

    • 肥皂：

  • 独立于传输协议（可以是HTTP，FTP，TCP，UDP，命名管道，共享内存甚至电子邮件）。
  • 只需要传输协议能够发送和接收文本（例如在HTTP上，只使用POST动词）。
  • 严格定义来回传递的消息的格式。 SOAP消息包含数据，要执行的操作，头文件和失败时的错误细节。
  • 消息安全性由WS- *标准提供，并且是端到端的。
  • 最初打算用于任意RPC调用。

    • 以上列表中的项目2和3是不兼容的要点。

    REST的目标之一是cachability，因为资源需要由uri（查询字符串）来标识。 在soap中发布请求，因此对于不同的请求你有相同的uri，因此资源不能唯一地由ur标识

    链接地址: http://www.djcxy.com/p/71427.html

    上一篇: Why isn't SOAP

    下一篇: JSON/REST over HTTPS + WS Security possible?