我正在编写一个只做一件事的小应用程序：获取一些用户提供的数据，对其进行一些分析，然后为该数据返回一个“标签”。我在想客户应该GET或者POST他们的请求/getTag才能得到回复。
当客户端执行此操作时，服务器上没有存储任何内容，因此使用 POST 感觉很奇怪。然而，分析也没有统一的 URI，所以使用 GET 感觉很奇怪，因为它会根据提供的数据返回不同的东西。
用 REST 表示此功能的最佳方式是什么？
问问题
155 次
5 回答
2
“最好的方法”是做最适合您的应用程序及其需求的任何事情。不知道，这里有一些想法：
GET是最合适的动词，因为您没有在服务器上创建或存储任何东西，只是检索服务器提供的东西。不要
get像你建议的那样把这个词放在 URI 中。HTTP 已经提供了类似的动词，所以只需使用/tagandGETit 代替。您应该为此资源使用易于理解（或“酷”）的 URI，并将数据作为查询参数传递。我不会担心它感觉很奇怪（请参阅此问题的答案以找出原因）。
总而言之，只需GET打开/tag?foo=bar&beef=dead，就完成了。
于 2012-04-15T00:45:56.143 回答
1
POST 可以代表执行一个动作。该操作不必是数据库操作。
您真正创建的是一个远程过程。RPC 通常都是 POST。我认为这不适合 REST，但这并不妨碍您使用简单的 URL 和 JSON。
于 2012-04-15T00:42:08.757 回答
1
在我看来，您或生成原始数据的用户可能希望生成的标签保持不变，不是吗？
如果这是可能的，那么我会将其编写为POST /tags并将/tags/:id资源 URI 作为 Location: 标头传回。
如果我真的不关心持久化生成的标签，我会考虑“用户生成的数据”是什么以及在幕后进行了多少处理。如果“标签”与传递到系统的任何数据都足够不同，GET /tag那么 API 使用者可能会感到困惑。
于 2012-04-15T02:52:36.887 回答
0
您可以使用GET和POST：
GET /tag?data="..." -> 200, tagGET 方法意味着检索由 Request-URI 标识的任何信息（以实体的形式）。如果 Request-URI 指的是数据生成过程，则生成的数据应作为响应中的实体返回，而不是过程的源文本，除非该文本恰好是该过程的输出。
POST /tag {data: "..."} -> 200, tagPOST 方法执行的操作可能不会产生可由 URI 标识的资源。在这种情况下，200（正常）或 204（无内容）是适当的响应状态，具体取决于响应是否包含描述结果的实体。
根据 HTTP 标准/方法定义部分。
如果我是你，我会使用GET（并且POST仅当你想发送文件时）。
于 2013-12-02T08:30:10.867 回答
0
我将支持 Brian 的回答：使用GET. 如果相同的输入参数返回相同的输出，并且您并没有真正创建任何东西，那么它是一个幂等操作，因此非常适合GET.
于 2012-04-15T07:06:49.410 回答