使用 http status 202 进行异步操作 [英] Use http status 202 for asynchronous operations

问题描述

我正在为接受用户提供的数据的服务编写 REST API.我想保持所有操作完全异步，这包括 PUT、POST、DELETE 甚至 GET 请求.我的想法是接收请求，对其进行足够的处理以确保它是一个有效的请求，然后传递一个 HTTP 202 接受的响应以及一个数据最终可用的 url 和一个令牌，以便后续请求可以与处理过的数据相匹配.如果请求无效，我将发送 HTTP 400.

I am writing a REST API for a service that will accept user contributed data. I would like to keep all operations completely asynchronous, this includes PUT, POST, DELETE and perhaps even GET requests. My idea is to receive the request, process it enough to ensure it is a valid request and then pass a HTTP 202 accepted response along with a url where the data will eventually be available and a token so that subsequent requests can be matched to processed data. If the request is invalid then I will send a HTTP 400.

然后客户端将负责检查我在未来某个时间提供给他们的 url 并传递令牌.如果数据可用，我将返回一个正常的 200 或 201，但如果我仍在处理请求，我将发送另一个 202，表明处理尚未完成.如果处理数据时出错，我将根据需要发送 4xx 或 5xx 状态.

The client will then be responsible to check the url I provided them at some time in the future and pass along the token. If the data is available I return a normal 200 or 201 but if I am still processing the request I will send another 202 indicating the processing hasn't completed. In case of errors processing the data I will send 4xx or 5xx status as necessary.

我想这样做的原因是我可以将所有有效请求转储到请求池中，并让工作人员从队列中提取并处理可用的请求.由于我不知道可用的池大小或可用工作器的数量，因此我无法确定我是否可以足够快地处理请求以满足 Google App Engine 的 30 秒限制.

The reason I want to do this is so I can dump all valid requests into a request pool and have workers pull from the queue and process requests as they are available. Since I don't know the pool size or number of workers available I can't be certain that I can get to requests fast enough to satisfy the 30 second limit of Google App Engine.

我的问题是:我是否通过以这种方式处理请求来破坏 REST?例如，浏览器似乎需要立即响应请求.对于我的 HTML 页面，我计划使用结构化页面进行响应，然后使用 AJAX 来处理数据请求.

My question is: am I perverting REST by processing requests in this manner? Browsers, for instance, seem to require immediate responses to requests. For my HTML pages I plan to respond with the structured page and then use AJAX to process the data requests.

我对以这种方式使用 REST 处理数据的任何意见或经验最感兴趣.

I'm mostly interested in any opinions or experience in processing data using REST in this manner.

推荐答案

我认为你的解决方案很好，Http status 202 是 正确的响应在这种特定情况下使用，表明请求已被接受进行处理，但处理尚未完成.

I think that your solution is fine, the Http status 202 is the proper response to use in this specific case indicating that the request has been accepted for processing, but the processing has not been completed.

我将在您的工作流程中稍微改变的是后续请求的 Http status.

What I would slightly change in your workflow are the Http status of the subsequent requests.

如您所说，202 响应 应返回一个 Location 标头，指定客户端应用于监视其先前请求状态的 URL.
调用这个 Check-the-status-of-my-process URL，而不是在进程挂起的情况下返回 202，我会返回:

As you said, the 202 response should return a Location header specifying the URL that client should use to monitor the status of its previous request.
Calling this Check-the-status-of-my-process URL, instead of returning a 202 in case of process pending, I would return:

1. 200 OK 当请求的进程仍然挂起时.响应应描述进程的待处理状态.
2. 201 Created 处理完成后.GET/PUT/POST 情况下的响应应包含请求/创建/更新资源的位置.

1. 200 OK when the requested process is still pending. The Response should describe the pending status of the process.
2. 201 Created when the processing has been completed. The Response in case of GET/PUT/POST should contain the Location to the requested/created/updated resource.

这篇关于使用 http status 202 进行异步操作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！