web-services - 我应该通过 HTTP RESTify 我的 RPC 调用吗？

Question

我们有 RPC 的 HTTP 网络服务。它们返回表示检索或创建的对象的 XML。我想知道“重新调整”服务的优势(如果有的话)。

发帖 http://www.example.com/createDoodad

获取 http://www.example.com/getDoodad?id=13

获取 http://www.example.com/getWidget?id1=11&id2=45

发帖 http://www.example.com/createWidget

发帖 http://www.example.com/createSprocked

我看到的一件事是我们不需要每个资源的表示，我们也不需要支持所有资源的所有操作(GET、PUT、POST、DELETE)。
基本上我的问题是这个。

说服我应该使用restful服务而不是RPC over HTTP，那些restful服务应该是什么？

Answer 1

一方面，一切都与语义有关，URI 是统一的 资源指标。 HTTP 提供了 GET、POST、PUT 和 DELETE 资源的方法。 HTTP header 指定我想要接收或发送信息的格式。这一切都可以通过 HTTP 协议(protocol)轻松获得。

因此，您可以重用用于 HTML 输出的相同 URL 以使用 HTTP 的方式获取 XML、JSON。

XML-RPC和 SOAP基于 XSD 或 WSDL 文件描述的调用方法，而 REST 基于获取/修改资源。区别很微妙，但很明显。 URL 仅描述资源而不是 Action ，这在 SOAP 和 XML-RPC 中经常出现。

REST 的好处是您可以利用 HTTP 动词来修改资源，如可以命名为 create/new/add 等的方法调用。有意义的 HTTP 状态代码而不是不同类型的错误响应，并且能够指定不同的以标准方式在同一资源上格式化。

您也不必接受 RESTful 资源上的所有动词，例如，如果您想要只读资源，只需返回 405 状态代码 Method Not Allowed在任何不是 GET 的动词上。

您应该重做对 REST 的 RPC 调用吗？不，我不这么认为。好处不会超过开发时间。在设置新的 Web 服务时应该学习 REST 吗？是的，我个人确实如此认为，使用 REST 资源会感觉更自然，并且可以更快地增长。

编辑

我认为 REST 胜过 XML-RPC/SOAP 的原因是，在开发网站时，您已经将输出的所有必要数据聚合为 HTML，您还为 POST 主体编写了验证代码。为什么要仅仅因为传输标记更改而要更改为不同的协议(protocol)？

这样，当您设计一个新网站(语言不可知)时，如果您真的将 URI 视为资源，您基本上将您的 URI 用作方法调用，并在方法调用前加上 HTTP 动词。

也就是说，/products/12 上的 GET 带有 HTTP header Accept: application/json;基本上(假想)转化为 getProducts(12,MimeType.Json) .

这个“方法”然后必须做几件事

检查我们是否支持 JSON 作为 MIME 类型。 (验证请求)

验证请求数据

产品 12 的汇总数据。

格式化为 JSON 并返回。

如果在 future 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 的动词部分成为了 URI 的一部分，但请注意，ASP.NET MVC 绝不会强制您这样做(或任何与此相关的事情)。

如果您至少要选择一个框架，他们应该:

将 URI 绑定(bind)到服务器上的方法

支持 Object 转 JSON/XML 等序列化。如果你必须自己写这个是很痛苦的，这取决于语言，不一定太难。

公开某种类型安全的请求助手，以帮助您确定请求的内容，而无需手动解析 HTTP header 。