我希望实现一个允许上传文件的RESTful HTTP API。在客户端生成并上载新文件之前，服务器需要确定是否需要新文件。此外，上传应该可以重定向到另一个服务器，第二步的PUT语义可以使这更容易。
到目前为止，我提出了以下想法：
POST的文本数据为/files，服务器根据该数据决定是否需要生成和上传下一个文件429 Too Many Requests和Retry-After标题201 Created和Location标头回复，告诉客户端文件的URL PUT
这是一种有效的方法吗？
我最不确定的是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标头之外什么都没有返回，但它与资源存在意味着什么有相同的概念性问题
另一种选择是通过将/files重命名为/file-upload-url-generator并将网址作为实际内容返回（使用200 OK，使API明确说明发生了什么。 ）。但是，我不满足于失去一致性和设计更复杂（使用Location标题似乎很好）。
答案 0 :(得分：1)
201的问题在于它必须包含正文 - 不仅要符合REST，还要兼容客户端库 - 如果标有201的响应不符合，则某些客户端库会抛出异常包含任何数据。但是资源有效或无效的意义201是良好的响应代码。资源已经创建，状态无关紧要。
202似乎有点尴尬 - 它表示服务器端处理而不是客户端。
就我个人而言，我会为{1}}找到第一个端点以及提到的204标头。响应很明确：资源已创建，可在此处找到。第二个端点可以仅回复Location个请求并做出适当的反应。