哪种 HTTP 重定向状态代码最适合此 REST API 场景？

Question

我正在开发 REST API。关键对象（“名词”）是“项目”，每个项目都有一个唯一的 ID。例如，要获取 ID 为 foo 的项目的信息：

GET http://api.example.com/v1/item/foo

可以创建新项目，但客户端无法选择ID。相反，客户端发送一些代表该项目的信息。因此，要创建一个新项目：

POST http://api.example.com/v1/item/
hello=world&hokey=pokey

使用该命令，服务器会检查我们是否已经有信息 hello=world&hokey=pokey 的项目。所以这里有两种情况。

情况1：该项目不存在；它被创建了。这个案子很简单。

201已创建
位置：http://api.example.com/v1/item/bar

情况 2：该项目已存在。这就是我正在努力的地方......不确定使用什么是最好的重定向代码。

301 永久移动？ 找到 302？ 303 看看其他？ 307临时重定向？ 位置：http://api.example.com/v1/item/foo

我研究了维基百科描述 和 RFC 2616，而且这些似乎都不完美。以下是我在这种情况下寻找的具体特征：

重定向是永久性的，因为 ID 永远不会改变。因此，为了提高效率，客户端可以而且应该向 ID 端点发出所有未来的请求直接地。这表明 301，因为其他三个是临时的。

即使此请求是 POST，重定向也应使用 GET。这建议使用 303，因为从技术上讲，所有其他请求都应该重用 POST 方法。实际上，浏览器将使用 GET 来表示 301 和 302，但这是一个 REST API，而不是供普通用户在浏览器中使用的网站。

它应该广泛使用并且易于使用。具体来说，303 是 HTTP/1.1，而 301 和 302 是 HTTP/1.0。我不确定这是一个多大的问题。

在这一点上，我倾向于 303 只是为了在语义上正确（使用 GET，不要重新 POST），并且只是吸收“临时”部分。但我不确定 302 是否会更好，因为实际上它的行为与 303 相同，但不需要 HTTP/1.1。但如果我沿着这条线走下去，我想知道 301 是否因为同样的原因加上“永久”部分更好。

想法赞赏！

---

编辑：让我尝试用一​​个更具体的示例来更好地解释此“获取或创建”操作的语义：URL 缩短。无论如何，这实际上更接近我的应用程序。

对于 URL 缩短器来说，迄今为止最常见的操作是通过 ID 进行检索。例如，对于 http://bit.ly/4Agih5，bit.ly 收到的 ID 为 4Agih5，并且必须重定向用户访问其相应的 URL。

bit.ly 已经有一个 API，但它并不是真正的 RESTful。为了举例，让我编写一个更加 RESTful 的 API。例如，查询 ID 可能会返回有关它的各种信息（例如分析）：

GET http://api.bit.ly/item/4Agih5

现在，如果我想向bit.ly 简而言之，我事先不知道我的URL的ID，所以我不能使用PUT。我会使用 POST 代替。

发布http://api.bit.ly/item/
url=http://stackoverflow.com/（但已编码）

如果 bit.ly 之前没有见过此 URL，它将为其创建一个新 ID，并通过 201 Created 将我重定向到新身份证。但如果它看到了该 URL，它仍然会重定向我而不做任何更改。这样，我可以通过任何一种方式点击该重定向位置来获取缩短的 URL 上的信息/元数据。

就像这个 URL 缩短示例一样，在我的应用程序中，冲突并不重要。一个 URL 对应一个 ID，仅此而已。因此，URL 之前是否被缩短并不重要；无论哪种方式，将客户端指向它的 ID 都是有意义的，无论是否需要首先创建该 ID。

所以我可能不会改变这种方法；我只是问最好的重定向方法。谢谢！

Answer 1

我赞成 303。假设现在 hello=world&hokey=pokey 唯一标识了项目 foo，但后来项目 foo 的 hokey 值更改为“smokey”？现在，这些原始值不再是该资源的唯一标识符。我认为临时重定向是合适的。

Answer 2

我认为您在这种情况下苦苦挣扎的原因之一是因为（除非我们遗漏了一些关键信息）交互不太符合逻辑。

让我解释一下我为什么这么想。最初的前提是用户请求创建一些东西，并且已经为他们希望创建的资源提供了一些关键信息。

然后，您声明如果该关键信息引用现有对象，那么您希望返回该对象。问题是用户不希望检索现有对象，而是希望创建一个新对象。如果他们无法创建资源，因为资源已经存在或存在密钥冲突，则应告知用户该事实。

当用户尝试创建新对象时选择检索现有对象似乎是一种误导性的方法。

如果资源已存在并包含指向实体正文中现有对象的链接，也许一种替代方法是返回 404 Bad 请求。客户端应用程序可以选择接受错误请求错误，并简单地跟踪现有实体的链接，从而向用户隐藏问题。这将是客户端应用程序的选择，但至少服务器的行为方式清晰。

---

基于新的例子，让我建议一种完全不同的方法。它可能不适用于您的情况，因为细节决定成败，但也许会有所帮助。

从客户端的角度来看，它实际上对服务器是创建新的缩短的 URL 还是撤回现有的 URL 不感兴趣。事实上，服务器是否需要生成新的ID是一个完全隐藏的实现细节。
隐藏创建过程可能非常有价值。也许服务器可以提前预测很快就会请求与会议等活动相关的大量短网址。它可以在相当长的时间内预先生成这些 URL，以平衡服务器上的负载。

所以，基于这个假设，为什么不直接使用

GET /ShortUrl?longUrl=http://www.example.org/en/article/something-that-is-crazy-long.html&suggestion=crazyUrl

如果 url 已经存在那么你可能会回来

303 See Other
Location: http://example.org/ShortUrl/3e4tyz

如果它以前没有，你可能会

303 See Other
Location: http://example.org/ShortUrl/crazyurl

意识到这看起来像我们通过创建一些响应来破坏 GET 的规则GET，但我相信在这种情况下它没有任何问题，因为客户端没有要求创建缩短的 URL，并且实际上并不关心任何一种方式。它是幂等的，因为调用它多少次并不重要。

一个我不知道答案的有趣问题是代理是否会缓存初始 GET 和重定向。这可能是一个有趣的属性，因为其他用户对同一 URL 的未来请求可能永远不需要实际到达原始服务器，代理可以完全处理该请求。

Answer 3

POST 不支持“查找或创建”方法。服务器无法告诉客户端“我会创建它，但它已经存在。在此处查找现有条目”。由于请求不成功，所有 2xx 代码均不起作用。所有 3xx 代码都不起作用，因为其目的不是将 POST 重定向到新资源。 303 也不合适，因为没有任何改变（参见 303 规范）。

您可以做的是向客户端提供一个与 PUT 一起使用的表单或模板，告诉客户端如何构建 PUT URI。如果 PUT 结果为 200，则客户端知道该资源已存在；如果返回 201，则表明已创建新资源。

例如：

URI 模板：http://service/items/{key}

PUT http://service/items/456

[数据]

已创建 201

或

PUT http://service/items/456

[数据]

200 好

您也可以执行“创建但执行”操作不使用 If-None-Match 替换“如果存在”：

PUT http://service/items/456
If-None-Match: *

[data]

412 Precondition failed 

Jan

Answer 4

从客户的角度来看，我认为您可以为案例 2 发送一个 201 ，就像案例 1 一样，因为现在记录已“创建”给客户。

Answer 5

HTTP 1.1。规范 (RFC 2616) 建议 303:

303 See Other

可以在不同的 URI 下找到对请求的响应，并且
应使用该资源上的 GET 方法进行检索。这个方法
存在主要是为了允许 POST 激活脚本的输出
将用户代理重定向到选定的资源。新的 URI 不是
替换最初请求的资源的参考。