rest - 使用可重定向 PUT 上传文件的 RESTful 设计是什么？

Question

我希望实现一个允许上传文件的 RESTful HTTP API。服务器需要在客户端生成并上传新文件之前决定是否需要新文件。此外，上传应该可以重定向到另一台服务器，第二步的 PUT 语义将使这更容易。

到目前为止，我想到了以下想法:

• 客户端POST文本数据到/files，服务器据此决定是否需要生成和上传下一个文件
• 如果不是，服务器将响应 429 Too Many Requests 和 Retry-After header
• 如果是，服务器响应 201 Created 和一个 Location header 告诉客户端文件的 URL
• 然后客户端继续生成文件并将其PUT到URL

这是一种有效的方法吗？

我最不确定的是 201 Created 是否合适。它表明创建了一个资源，但它真的是空的并且还无效吗？ GET 它将不再给出 404 Not Found 但 405 Method Not Allowed (因为只有 PUT 是)，所以从这个意义上说，资源存在。如果在一段时间内没有文件被 PUT，服务器可能会使它过期并最终给出 404 Not Found，或者可能是 410 Gone。从形式上讲，创建资源意味着什么？

我还考虑了 202 Accepted，因为处理尚未完成，但在这种情况下下一个处理是由执行请求的客户端完成的，而不是比服务器；因此我也不确定这是否合适——它不应该等待任何东西可用；它应该继续自行提供。然后是 204 No Content，它可能比 201 Created 稍微好一些，因为除了 Location header 之外没有返回其他内容，但它具有与资源存在的意义相同的概念问题。

另一种选择是通过将 /files 重命名为 /file-upload-url-generator 并返回一个 URL，使 API 非常明确地说明正在发生的事情作为实际内容(200 OK)。但是，我对失去统一性和更复杂的设计感到不高兴(使用 Location header 似乎不错)。

Answer 1

201 的问题是它必须包含正文 - 不仅要符合 REST 标准，而且要与客户端库兼容 - 如果响应标记为 201<，一些客户端库会抛出异常 不包含任何数据。但资源是否有效的感觉 201 是很好的响应代码。资源已创建，状态无关紧要。

202 看起来有点尴尬，因为正如您所指出的那样 - 它表示服务器端处理而不是客户端。

我个人会选择 204 作为第一个端点以及提到的 Location header 。响应很明确:资源已创建，可在此处找到。第二个端点可能只回复 PUT 请求并做出适当的 react 。