REST Web 服务，仅用于数据库访问？答案

【问题标题】：REST web services, just for database access only?REST Web 服务，仅用于数据库访问？
【发布时间】：2010-11-01 11:22:57
【问题描述】：

我一直在阅读 REST Web 服务，并希望实现自己的 REST 服务。

我在互联网上看到的所有示例都与数据库访问有关。但是我想要实现的与访问数据库无关。

我想创建一个 REST 服务，该服务允许将大字符串和各种其他参数传递到资源中，并返回一个 xml 结果集。没有任何内容被创建或更新到数据库中，也没有从数据库中检索任何内容。它将数据传递给一个复杂的处理过程，然后返回结果。

我的问题在于我使用什么动词？

我觉得我应该使用 GET 动词来与最佳实践保持一致，但查询有时可能非常大，并且在查询字符串上传递它是可行的。

这给我留下了 POST。这似乎符合我想要实现的目标，但我认为它再次脱离了 REST 最佳实践！

REST 是否仅在想要与数据库交互时使用？

我应该放弃使用 rest 并创建 SOAP 服务的想法吗？

更新我的 REST 服务是分析文章并返回给定文章的关键字报告。鉴于此，资源为“关键字”，对此的 POST 将返回完整报告。我当时正在考虑关键字/推荐的第二个 uri，对此的 POST 将返回提交文章的一些推荐关键词。这符合 REST 吗？

【问题讨论】：

您能否更明确地说明您的应用程序设计，例如您如何将应用程序分解为动词和名词。
您应该使用 GET，因为 GET 允许缓存，而且听起来您系统的相同输入总是会产生相同的响应。
该协议确实非常适合数据库应用程序，但那是因为数据库会自动为您描述其资源。例如，一张桌子可以被称为人。然后很明显，这些方法对简单描述的实体的作用比对一堆实体的作用。我认为如果您的查询字符串变得太大，请重构您的应用程序，首先查看数据使用情况和描述。可能是设计问题。
既然您已经阐明了您实际想要实现的目标，请使用 PUT 方法，文章是一种新资源，因此您将其放入您的应用程序中。您的应用程序从未处理过此资源，因此您不应使用 POST。由于它是一种新资源，因此您无法使用 GET 对其进行查询，因为应用程序不知道您在说什么。
@WeNeedAnswers - 你不认为 Darrel Miller 根据 HTTP 规范给出的关于 POST 定义的答案是正确的方法。 PUT 旨在用于更新已存在或应用程序已知的资源。在我的例子中，网络服务不会知道它需要处理的文章的任何信息。

标签： rest post get service

【解决方案1】：

REST 不需要数据库，事实上 REST 与数据库无关。

您描述的场景正是 POST 的目的。引用HTTP specs的最新版本：

POST方法用于请求源服务器接受请求中包含的陈述作为目标要处理的数据资源.资源。

你可以这样做：

POST /ArticleProcessor
Content-Type: text/plain

发送您的文章文本，响应可能是：

Status: 200 OK
Content-Type:application/xhtml

<html>
<title>Results of keyword processing</title>
<body>
<a rel="FullReport" href="/reports/2343434/full">Full Report</a>
<a rel="TopKeywords" href="/reports/2343434/top">Top Keywords</a>
</body>
</html>

【讨论】：

现在我错过了，为什么在所有 REST 互联网帖子中他们都说 POST 用于 CREATE 或 ADD...这不是 POST 的正确定义。
@Stuart 因为定义之一就是这样做。不幸的是，RFC2616 强调了人们在第一段停止阅读。 IETF httpbis 工作组正在制定的更新规范不再强调该特定用法以防止混淆。
您的回答会帮助很多人，因为 POST 的定义很明确。 POST 不仅仅用于添加或创建资源，这简直是荒谬的！如果只有我在周末阅读的网站会更新那里的内容！这需要对所有 REST 爱好者进行病毒式传播。谢谢
@Stuart 我认为这是一群非常聪明的人在过去几年中重新编写 HTTP 规范以使其更清晰的原因之一。不过你是对的，网络上关于 REST 的错误信息比好的信息要多

【解决方案2】：

请记住，与 SOAP、XML-RPC 等类似，REST 只描述一个接口，而不是提供该接口的应用程序的实现。没有理由，为什么 REST 应该只用于 CRUD 数据库场景。

我会使用以下方法来解决您的问题：

让客户端通过POST将其数据发送到带有POST参数（“大字符串和各种其他参数”）的通用URI（例如http://example.com/processor）并返回结果资源的URI（例如http://example.com/results/<unique-id> )。客户端现在可以从那里GET“复杂处理过程”的结果。

【讨论】：

我喜欢这个想法，但是，现在我们进入了国家领域。而且我相信 REST 服务应该是无状态的。将结果集存储在数据库中以便可以调用 GET 来检索结果可能是完全符合 REST 架构的唯一方法。在我看来，这对于我想要实现的目标来说似乎很昂贵！
@Stuart 通过为状态提供 URI，您将状态变为“资源”状态。这在 REST 中是允许的。将其存储在物理磁盘上还是存储在内存中，完全取决于您。
@Stuart，这个答案对你有什么帮助？我很想知道，除非我误读了这个问题:)
@WeNeedAnswers - 我已在您的回答中添加了评论

【解决方案3】：

您可以对“最佳实践”持保留态度。我不确定是否有人真正关心 POST 是否会影响数据库，只要它正确执行您记录的任何操作即可。

只要您的用户知道您期望什么行为就可以了。

【讨论】：

更改协议的含义将失去互操作性。在 HTTP 的情况下，可以缓存 GET 检索到的数据。使用带有 GET 语义的 POST 来检索数据将失去缓存数据的可能性。
好的，太好了，你能指出任何不涉及数据库的 REST 服务示例吗？
Martin，就我而言，缓存数据不是问题，它不会影响我尝试实现的“服务”。但是就像你说的使用 POST 来获取结果集可能是错误的做法？

【解决方案4】：

我会坚持使用 REST，如果您也确实如此，请使用 POST 方法。没有 REST 不仅适用于数据库。然而，它应该很容易使用而没有 SOAP 的繁琐。 SOAP 尝试执行的许多任务（例如身份验证）都可以通过直接 http 完成。这个想法是 REST 是轻量级的、响应迅速的、易于理解和使用的。休息我将描述为与一位老阿姨的对话，她总是忘记你是谁。也许当您查询 REST 应用程序时，您可能需要将其分解为名词和动词，例如针对人员资源或地点资源的查询，而不是尝试同时查询地点和人员，将两者分开并询问每个资源您的查询。这样做确实使协议变得健谈，但如果您真的关心网络流量，那么我会使用 XML-RPC 或 SOAP。

【讨论】：

谢谢，我的服务是分析文章并返回给定文章的关键字报告。鉴于此，资源为“关键字”，对此的帖子将返回完整报告。我当时正在考虑第二个关键字 uri/建议返回提交文章的一些推荐关键词。这符合 REST 吗？
资源不会是Articles，查询就是针对这个Article资源，想想两者的关系，一个Article可以有很多关键词。例如，someplace.com/Articles?Full=No 将以缩写形式返回所有文章的列表，而 someplace.com/Articles?ID=1234 将返回完整的文章（应该只有一个 :)），其中包含与其相关的所有关键字和数据。
我会进一步说明这个例子，要查询带有某些关键字的文章，你可以继续说 someplace.com/Articles?keywords=one,two,three,four,five,six,seven ,8 等您设计的所有其他属性都可以围绕此完成，例如 Full=No, MaxReturn=400 等
@WeNeedAnswers - 我不认为我的资源是“文章”，你的权利，一篇文章可以有很多关键字。但是我的服务不存储文章，它需要一篇 POSTED 文章并对其进行处理以返回关键字。如果我想要一个查询文章数据库的服务并希望对其运行查询，那么您的示例将是正确的。
如果您发布新文章，您应该使用 PUT 方法。返回可以作为 HTTP 数据包返回，其中包含 Content 中的关键字。