REST适用于文档样式的Web服务吗？

Question

RESTful和文档/消息风格似乎是现在实现Web服务的两种趋势。通过这个，我的意思是REST与SOAP，文档风格与RPC风格。

我的问题是REST与文档式Web服务的兼容性如何。根据我对REST的有限知识，它利用http GET / POST / PUT / DELETE谓词对URL表示的远程资源执行类似CRUD的操作，这使得它更加“繁琐”和远程方法一样，即RPC样式。另一方面，文档样式的Web服务强调粗粒度调用，即发送具有复杂信息的批量请求文档，并期望响应文档也返回复杂信息。我无法看到如何通过REST很好地完成它，而不是只为“响应”声明一个资源并且一直使用POST动词（这将破坏REST的目的）。

由于我是文档风格和RESTful网络服务的新手，请原谅我，并在上述假设中指出任何无知。谢谢！

Answer 1

您对REST的理解是错误的。这并不奇怪，也不是你的错。关于REST在互联网上浮动的信息远远多于有效信息。

REST更适合粗粒度文档样式类型的分布式接口，而不是面向数据的CRUD接口。虽然CRUD操作与HTTP GET / PUT / POST / DELETE之间存在相似之处，但是对于应用程序的体系结构存在微妙的差异。

我认为你的意思不是REST而不是SOAP。可以通过SOAP执行REST，但据我所知，没人会这样做，我从未见过有关它的文章。

SOAP通常用于“Web服务”，REST通常通过HTTP完成。

Answer 2

只要您将文档视为资源，REST就非常适合与文档一起使用。

GET允许您检索文档。明显。

POST允许您创建文档。您的API无需要求文档的完整内容来创建它。由您决定实际创建文档所需的内容。

PUT允许修改文档。同样，无需强制客户端在每次要保存时发送整个文档。您的API可能支持通过PUT请求发送的增量更新。

DELETE显然删除了该文档。同样，您可以设计API，以便删除实际上不会破坏文档的每个位。您可以创建类似于回收站的系统。

REST和处理文档的好处是服务器响应包含了解响应所需的所有信息。因此，如果创建了一个新资源，您应该发送它的位置，如果移动资源，则应该发送它。等等。您需要记录的是要使用的数据类型（XML格式，JSON等）

标准HTTP方法就在那里，因为它们的行为已经定义，并允许客户端只要知道URI就可以轻松发现您的API。