高级REST API

Question

我们的REST API之一将导致执行长时间运行的进程.我们宁愿立即回复,而不是让客户等待很长时间.

因此,让我们考虑一下这个用例:申请人提交申请,最终会有结果.由于这是一个非常高规模的平台,我们不能将应用程序持久存储,而是必须将其放入队列进行处理.

在这种情况下,返回应用程序最终存在的URI是否可以接受,例如http://example.com/application/abc123？

同样,作为应用程序资源表示的一部分,返回结果文档的URI(表示有关应用程序的决策)是否可以接受？结果文档将在几分钟内不会创建,并且对其URI(或应用程序的URI)的HTTP GET将导致404,直到它们被持久化.

在这种情况下,最佳做法是什么？为资源分发"未来"URI是否可以接受？

Answer 1

我没有看到这种设计有任何问题,但仔细查看HTTP状态代码列表以获得更好的响应.恕我直言,第一个请求应该返回202接受:

该请求已被接受处理,但处理尚未完成.

而对结果最终应该在URL的请求应该在此期间返回204 No Content(？):

服务器成功处理了请求,但未返回任何内容

当然,处理完成后最终应该返回200 OK.

Answer 2

问题

您想知道如何为执行计算或验证数据等任务提供资源抽象。

解决方案

将处理函数视为资源，并使用 HTTP GET 获取包含处理函数输出的表示。使用查询参数向处理函数提供输入。

这仅需要对代表处理功能的 URI 进行 GET 请求。您的示例“ http://example.com/application/abc123”URI。返回响应时，您将包含您现在拥有的信息，并使用 HTTP 代码来指示处理状态，正如 Tomasz 已经建议的那样。

但是...，如果后续应用程序处理以任何方式存储或修改数据，则不应使用此方法。

GET 请求不应该有副作用。如果应用程序的提交无论如何都会导致存储新信息/数据（即使仅在从队列中处理之后），则应使用 PUT 或 POST 请求，并将应用程序的数据放在请求正文中。请参阅“为什么不应在 HTTP GET 请求上修改数据？ ”了解更多信息。

如果应用程序的提交存储或修改数据，请使用异步处理模式：带有应用程序详细信息的 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”。