在处理不同类型的 GET 时我应该如何格式化我的 REST API答案

【问题标题】：How should I format my REST API when dealing with different types of GET在处理不同类型的 GET 时我应该如何格式化我的 REST API
【发布时间】：2014-02-14 17:49:11
【问题描述】：

假设我有和订购资源。为了获得我想要的资源，我会这样做：

GET /orders/{someId}

问题是当有不同类型的获取时我该怎么办。例如，一个 GET 来编辑订单或一个 GET 来审查订单。通常情况下，您只需对两者都使用orders/{someId}，但在这种情况下，我需要为每一个都做一些不同的业务逻辑（一些审计）。

也许我可以这样做：

GET /orders/{someId}?type=review

但这似乎是错误的。想法？

【问题讨论】：

这里似乎有很多好的建议stackoverflow.com/questions/4024271/…
为什么看起来不对？我看不出有什么问题。
'一个 GET 来编辑订单或一个 GET 来审查订单' 你是什么意思？ GET 返回资源的表示，它不会改变它。
正确，GET 不会修改订单。 'a GET to edit' 是指获取订单以进行编辑，而不是实际编辑订单。那将是一个 PUT（大部分时间）。
@DarrelMiller 我只是想确保它有意义。这似乎是错误的，因为它对我来说更像是一个动词而不是一个名词。就像 flopo 提到“GET /orders/{someId}/action”一样，我认为一切都应该是一个名词，而不是一个动作。但是就像您评论的那样，审查和编辑可以视为资源，这不是一个动作。如果您想取消订单，您会怎么做。我的第一个想法是 PUT /orders/{id}/cancelRequest?

标签： rest restful-url restful-architecture

【解决方案1】：

GET /orders/{someId}/action

满足您的需求

GET /orders/{someId}/edit
GET /orders/{someId}/review

GET 不应该修改该项目，所以我假设这个 URL 只是用于加载资源，而不是用于修改它....请澄清这一点

【讨论】：

我不修改资源，我只是添加一些审计信息，说明他们是否请求资源以便稍后编辑它或只是查看资源。至于你的建议，谢谢。您会将编辑和审阅视为单独的资源吗？这对我来说似乎很奇怪（不是类型请求参数更好）。
@testing123 是的，您的“编辑”表示和“审查”表示是不同的资源。无论您使用路径段还是查询参数都没有什么区别。
@flopo 我不同意对 url 进行操作的想法，因为 REST 完全是关于 url 是资源而不是操作（动词），但我想这只是你看待它的方式。正如 Darrel Miller 所说，它们可以被视为资源。

【解决方案2】：

您可以使用不同的 HTTP 方法（作为动词），具体取决于正在发生的操作。这将使您保持路径干净和简单。

例子：

GET /orders/{someId}
PUT /orders/{someId}
POST /orders/{someId}
DELETE /orders/{someId}

GET 用于检索，PUT 用于更新，POST 用于创建，DELETE 用于删除资源。这遵循基本的 CRUD（创建、读取、更新、删除）。如果您需要添加任何其他过滤器/参数，请使用查询参数。

【讨论】：

将 HTTP 方法等同于 CRUD 将使得使用 REST api 执行除 CRUD 之外的任何操作变得特别困难。 HTTP 方法比这灵活得多。
我并不是说要限制使用这 4 种 HTTP 方法。但是，对于 REST，这通常是它们的等同方式。我想举一个例子来说明如何考虑到这一点。当然，如果需要灵活性，这些方法可以用于许多不同类型的请求（RESTful 或非 RESTful）。
REST 将 HTTP 方法映射到 CRUD 的想法可能是混淆 REST 是什么的主要来源之一。我建议阅读此答案以澄清：stackoverflow.com/questions/19843480/…