我们有 RPC 的 HTTP Web 服务。它们返回表示检索或创建的对象的 XML。我想知道“恢复”服务的优势（如果有的话）。
我看到的一件事是我们不需要每个资源的表示，我们也不需要支持所有资源上的所有操作（GET、PUT、POST、DELETE）。基本上我的问题是这个。
说服我应该使用 RESTful 服务而不是 RPC over HTTP，那些 RESTful 服务应该是什么？
一方面，它与语义有关，URI 是一个统一资源指示符。HTTP 提供了 GET、POST、PUT 和 DELETE 资源的方法。HTTP 标头指定我想要接收或发送信息的格式。这一切都可以通过 HTTP 协议轻松获得。
因此，您可以重用用于 HTML 输出的相同 URL，以使用 HTTP 的方式获取 XML、JSON。
XML-RPC和SOAP基于调用由 XSD 或 WSDL 文件描述的方法，而 REST 基于获取/修改资源。差异是微妙但明显的。URL 仅描述资源，而不是像 SOAP 和 XML-RPC 那样经常描述的操作。
REST 的好处是，您可以利用 HTTP 动词来修改资源，就像可以命名为 create/new/add 等的方法调用一样。有意义的 HTTP 状态代码而不是不同类型的错误响应，并且能够指定不同的错误响应以标准方式对同一资源进行格式化。
您也不必接受 RESTful 资源上的所有动词，例如，如果您想要一个只读资源，只需Method Not Allowed在任何不是 GET 的动词上返回 405 状态代码。
您是否应该重做对 REST 的 RPC 调用？不，我不这么认为。好处不超过开发时间。设置新的 Web 服务时应该学习 REST 吗？是的，我个人确实这么认为，使用 REST 资源会感觉更自然，并且可以更快地增长。
编辑
我觉得 REST 胜过 XML-RPC/SOAP 的原因是，在开发网站时，您已经将所有必要的数据汇总到 HTML 中，您还为 POST 主体编写了验证代码。为什么仅仅因为传输标记发生变化就应该更改为不同的协议？
这样，当您设计一个新网站（与语言无关）时，如果您真的将 URI 视为资源，那么您基本上将 URI 用作方法调用，并在方法调用前加上 HTTP 动词。
也就是说，带有 HTTP 标头的 /products/12 上的 GETAccept: application/json;基本上（想象的）转换为getProducts(12,MimeType.Json).
这种“方法”必须做几件事
如果由于某种原因在接下来的 4 年内YAML将成为下一个大热潮，并且您的一位消费者希望以这种方式与您交谈，那么这种 MIME 类型比使用常规 Web 服务更容易插入。
现在产品 12 是您很可能还希望接受 HTML MIME 类型以显示所述产品的资源，但是对于像/product/12/reviews/14/您不需要 HTML 对应物的 URI，您只希望您的消费者能够发布到该 URL 到更新（PUT）/删除（DELETE）他们自己的评论。
将 URI 严格地视为资源，而不仅仅是网页的位置，而这些资源又与服务器端对方法调用的 HTTP 请求相结合，导致 URL 干净（SEO 友好）和（更重要的是？）易于发展。
我敢肯定，任何语言的框架都会自动为您将 URI 映射到方法调用。我不能推荐一个，因为我通常会推出自己的。
ASP.NET MVC 也按照相同的原理工作，但在我看来，它不会产生 RESTful URI。默认情况下，ASP.NET MVC 将动词作为 URI 的一部分，并指出，请注意，ASP.NET MVC 绝不会强迫您这样做（或其他任何事情）。
如果你至少要选择一个框架，他们应该：
尝试从 URL 中取出动词：
查询字符串不应用于以分层、非查询方式访问资源。缓存时通常会忽略查询字符串，这是危险且缓慢的。