【发布时间】：2016-06-14 06:10:49
【问题描述】：
我想知道您对这个概念的看法/cmets。如果有替代方案？如果这可行/有益？
据我了解，对于每一个http请求，服务器都会执行一些操作并返回一个http响应。
现在考虑任何场景，我们希望对服务器上运行的进程进行更多控制。
情况 1：http 请求发送 -> 服务器开始处理（正在处理的长任务） -> 用户关闭浏览器。 在这里，该过程仍然执行，消费服务器和http响应将在客户端被忽略。
这里的资源被浪费了。
情况2：http请求发送->服务器开始处理（长任务处理中）
这里客户端不知道服务器中运行的进程的状态。 客户端必须等到它收到 http 响应。
我的想法：在初始 http 请求和最终 http 响应之间，添加一个发送多个中间 http 响应的功能，该功能将携带有关在服务器端运行的进程的信息。
情况1的解决方案：http请求发送->服务器开始处理（长任务正在进行）->[返回进程id作为中间http响应]->用户关闭浏览器-> [使用进程ID发送http请求关闭服务器进程]
情况 2 的解决方案：http 请求发送 -> 服务器开始处理（处理中的长任务）-> [返回 http 响应，其中包含服务器上运行的进程的详细信息] -> [如果需要，执行任何操作]
如果我遗漏任何内容，请发表评论 :) 并纠正。
【问题讨论】：
-
这通常通过返回 202 Accepted 来完成，并带有
Location标头告诉您去哪里寻找结果。如果您想要持续更新，请使用 WebSockets。定义您自己的 HTTP 可能不是一个有效的路由转发，而且 SO 无论如何也不能真正帮助您完成该过程；我们不负责协议。 -
这听起来很简洁。去吧，实现它。
-
@RolandIllig 我认为当 OP 显然不理解任务的重要性时，用“去做”的方式将其送走并不是特别有建设性。
-
为了更好地了解所涉及的进程数量，请阅读对 HTTP 的最后一次更改到 2.0：http2.github.io/faq
-
那我也可能没看懂量级。对我来说，这听起来像是一个
POST /start-longrunning-task，它会返回12345，然后是几个GET /task-status/12345。在我看来，这为长时间运行的任务提供了一个不错的 API。
标签： http httprequest httpresponse