我们的一个REST API将导致长时间运行的进程执行。我们宁愿立即回复，而不是让客户等待很长时间。
因此，让我们考虑一下这个用例：申请人提交申请，最终会有结果。由于这是一个非常高规模的平台，我们不能将应用程序保存到存储中，而是必须将其放在队列中进行处理。
在这种情况下，返回应用程序最终生效的URI是否可以接受，例如http://example.com/application/abc123？
同样，作为应用程序资源表示的一部分，返回结果文档的URI（表示有关应用程序的决策）是否可以接受？结果文档将在几分钟内不会创建，并且对其URI（或应用程序的URI）的HTTP GET将导致404，直到它们被保留为止。
在这种情况下，最佳做法是什么？是否可以分发资源的“未来”URI？
答案 0 :(得分：6)
我认为此类设计没有任何问题，但请仔细查看list of HTTP status codes以获得更好的响应。恕我直言，第一个请求应该返回202接受：
请求已被接受处理，但处理尚未完成。
同时请求结果最终的URL请求返回204 No Content（？）：
服务器成功处理了请求，但未返回任何内容
当然，处理完成后它最终会返回200 OK。
答案 1 :(得分：1)
来自“RESTful Web Services Cookbook”
问题
您想知道如何为其提供资源抽象 执行计算或验证数据等任务。
解决方案
将处理函数视为资源，并使用HTTP GET进行提取 包含处理函数输出的表示。使用 查询参数以向处理函数提供输入。
这只需要代表处理函数的URI上的GET请求。您的示例“http://example.com/application/abc123”URI。返回响应时，您将包含现在的信息，并使用HTTP代码指示Tomasz已建议的处理状态。
但是......，如果后续的应用程序处理以任何方式存储或修改数据，则不应使用此方法。
GET请求不应该有副作用。如果应用程序的提交无论如何（即使只是在从队列中处理之后）导致存储的新信息/数据，您应该在请求的正文中使用PUT或POST请求以及应用程序的数据。有关详细信息，请参阅“Why shouldn't data be modified on an HTTP GET request?”。
如果他们的应用程序提交存储或修改数据，使用该模式进行异步处理：带有应用程序详细信息的POST或PUT请求。
例如
POST http://example.com/applications
返回“201 Created”，其中包含新应用程序资源的URI。
或
PUT http://example.com/applications/abc123
返回“201 Created”和
两者都会返回当时已知的任何资源信息。
然后，您可以安全地对新资源的URI执行GET请求，因为它们现在只检索数据 - 到目前为止应用程序处理的结果 - 并且不会存储或修改数据GET。
为了指示应用程序的处理进度，GET请求可以在响应中返回一些特定的状态代码（排队，处理，接受，拒绝），和/或使用HTTP响应代码。在任何一种情况下，只有在应用程序处理完成后才能返回“200 OK”。