我正在为接受用户贡献数据的服务编写 REST API。我希望所有操作保持完全异步，这包括 PUT、POST、DELETE 甚至 GET 请求。我的想法是接收请求，对其进行足够的处理以确保它是有效的请求，然后传递 HTTP 202 接受的响应以及数据最终可用的 url 和令牌，以便后续请求可以与处理后的数据相匹配。如果请求无效，我将发送 HTTP 400。
然后，客户端将负责在将来的某个时间检查我向他们提供的 url 并传递令牌。如果数据可用，我会返回正常的 200 或 201，但如果我仍在处理请求，我将发送另一个 202，指示处理尚未完成。如果处理数据时出现错误，我将根据需要发送 4xx 或 5xx 状态。
我想这样做的原因是这样我可以将所有有效请求转储到请求池中，并让工作人员从队列中提取并处理可用的请求。由于我不知道池大小或可用工作人员数量，因此我无法确定是否可以足够快地获取请求以满足 Google App Engine 的 30 秒限制。
我的问题是：我是否通过以这种方式处理请求来破坏 REST？例如，浏览器似乎需要立即响应请求。对于我的 HTML 页面，我计划使用结构化页面进行响应，然后使用 AJAX 来处理数据请求。
我最感兴趣的是以这种方式使用 REST 处理数据的任何意见或经验。
我认为你的解决方案很好，Http status 202 is the 正确的反应 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html在这种特定情况下使用表明请求已被接受处理，但处理尚未完成.
我要稍微改变一下你的工作流程是Http status的后续请求。
正如你所说，202 response应该返回一个Location header指定客户端应该用来监视其先前请求的状态的 URL。
调用这个检查我的进程的状态URL，如果进程挂起，我不会返回 202，而是返回：
-
200 OK当请求的进程仍处于待处理状态时。响应应描述流程的待处理状态。
-
201 Created当处理完成时。 GET/PUT/POST 情况下的响应应包含请求/创建/更新资源的位置。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
