首先，它与语义有关，URI 是一个统一的 Resource 指示符。 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 资源上的所有动词，例如，如果您想要只读资源，只需在任何不是 GET 的动词上返回 405 状态代码 Method Not Allowed。
您应该重做对 REST 的 RPC 调用吗？不，我不这么认为。好处不超过开发时间。设置新的 Web 服务时应该学习 REST 吗？是的，我个人确实这么认为，使用 REST 资源会感觉更自然，并且可以更快地增长。
编辑
我觉得 REST 胜过 XML-RPC/SOAP 的原因是，在开发网站时，您已经将所有必要的数据汇总为 HTML 输出，您还需要为 POST 主体编写验证代码。为什么仅仅因为传输标记发生变化就应该更改为不同的协议？
这样，当您设计一个新网站（与语言无关）时，如果您真的将 URI 视为资源，那么您基本上将 URI 用作方法调用，并在方法调用前加上 HTTP 动词。
也就是说，/products/12 上带有 HTTP 标头 Accept: application/json; 的 GET 基本上（想象的）转换为 getProducts(12,MimeType.Json)。
这个“方法”必须做几件事
- 检查我们是否支持将 JSON 作为 MIME 类型。 （验证请求）
- 验证请求数据
- 产品 12 的汇总数据。
- 格式化为 JSON 并返回。
如果由于某种原因在未来 4 年内 YAML 将成为下一个大热潮，并且您的一位消费者希望以这种方式与您交谈，则插入这种 MIME 类型比使用常规 Web 服务更容易.
现在产品 12 是您很可能还希望接受 HTML MIME 类型以显示所述产品的资源，但是对于像 /product/12/reviews/14/ 这样的 URI，您不需要 HTML 对应项，您只希望您的消费者能够发布到该 URL 以更新（PUT）/删除（DELETE）他们自己的评论。
将 URI 严格地视为资源，而不仅仅是网页的位置，而这些资源又与服务器端对方法调用的 HTTP 请求相结合，从而产生干净（SEO 友好）的 URL 和（更重要的是？ ) 易于开发。
我确信任何语言的框架都会自动为您执行 URI 到方法调用的映射。我不能推荐一个，因为我通常会推出自己的。
ASP.NET MVC 也按照相同的原理工作，但在我看来，它不会产生 RESTful URI。默认情况下，ASP.NET MVC 将动词作为 URI 的一部分，但请注意，ASP.NET MVC 绝不会强迫您这样做（或其他任何事情）。
如果您至少要选择一个框架，他们应该：
- 将 URI 绑定到服务器上的方法
- 支持对象到 JSON/XML 等的序列化。如果您必须自己编写，这会很痛苦，但取决于语言，并不是太难。
- 公开某种类型安全的请求助手，以帮助您确定请求的内容，而无需手动解析 HTTP 标头。