HTTP回调URL与WebSocket进行异步响应?

我有两个服务器:Golang和Python(2.7)。 Python(瓶)服务器具有要执行的计算密集型任务,并公开RESTful URI以开始执行流程。 也就是说,Go服务器发送:</ p>

HTTP GET到myserver.com/data

python服务器执行 计算,需要通知Go服务器处理完成。 我认为可以通过两种方式进行设计:</ p>


  1. Go向Python发送回调URL /数据,而python通过点击该URL进行响应。 例如:
    </ p>

    HTTP GET | myserver.com/data | 数据{callbackURI:goserver.com/process/results,类型:POST,响应:“ processComplete”} </ p> </ li>

  2. 已将基于WebSocket的响应从Python发送回Go 。</ p> </ li>
    </ ol>

    什么是更合适的设计? 是否有一个优点/缺点一个做另一个? 除了错误情况(服务器崩溃等)之外,Python服务器真正需要“通知”客户端的唯一一件事就是完成计算。 这是唯一的答复。</ p>

    在Go服务器上工作的团队并不精通基于websockets / ajax的Go客户端(我也没有。但是我从未写过 单行代码:)#1似乎更容易,但是却不知道这是一种公认​​的设计方法还是仅仅是一种破解? 建议在这方面进行什么操作?</ p>
    </ div>

展开原文

原文

I have two servers: Golang and Python (2.7). The Python (Bottle) server has a computation intensive task to perform and exposes a RESTful URI to start the execution of the process. That is, the Go server sends:

HTTP GET to myserver.com/data

The python server performs the computation and needs to inform the Go server of the completion of the processing. There are two ways in which I see this can be designed:

  1. Go sends a callback URL/data to Python and python responds by hitting that URL. E.g:

    HTTP GET | myserver.com/data | Data{callbackURI:goserver.com/process/results, Type: POST, response:"processComplete"}

  2. Have a WebSocket based response be sent back from Python to Go.

What would be a more suitable design? Are there pros/cons of doing one over the other? Other than error conditions (server crashed etc.,) the only thing that the Python server needs to actually "inform" the client is about completing the computation. That's the only response.

The team working on the Go server is not very well versed with having a Go client based on websockets/ajax (nor do I. But I've never written a single line of Go :) #1 seems to be easier but am not aware of whether it is an accepted design approach or is it just a hack? What's the recommended way to proceed in this regard?

dpa0760
dpa0760 我敢肯定这不是纯粹基于意见的。只有两种方法可以做到,趋势似乎是#2。我想知道#1在这方面的重要性。
大约 6 年之前 回复
doudou3213
doudou3213 这实际上是基于意见的,比任何东西都重要,我个人会选择第一个选项,即为每个请求分配唯一的ID,并让python脚本将其包含在processComplete调用中。
大约 6 年之前 回复

2个回答



这取决于发送这些信号的频率。 如果每秒多次,则保持websocket打开可能更有意义。 否则,请使用选项#1,因为它会减少开销,并且耦合更松散。 </ p>
</ div>

展开原文

原文

It depends on how often these signal are being sent. If it's many times per second, keeping a websocket open might make more sense. Otherwise, use option #1 since it will have less overhead and be more loosely coupled.

dqwh1209
dqwh1209 - 谢谢你的提示。 我想强调的是,这不是做事的“坏方法”,因此也不是问题。
大约 6 年之前 回复
douyoupingji7238
douyoupingji7238 -不幸的是,“服务器”是由不同的人在不同的时间写的。 尽管使用Python来实现Go服务器实现更为可取(因为在此之前使用Python编写了计算密集型过程:)。 但是,团队决定采用完全不同的语言来进行此设计。 这个决定是在我加入团队之前做出的;)
大约 6 年之前 回复
dty98339
dty98339 我以前亲自实现过这种模式,所以我已经看到了。 我几乎可以肯定会选择选项1。
大约 6 年之前 回复
doushen9863
doushen9863 我从未遇到过这种确切情况,不。 给您的问题:为什么Go中不包含计算内容? 会不会更快?
大约 6 年之前 回复
dqjcb132285
dqjcb132285 出于好奇,您是否看到#1被部署为一种模式? 为了回答您的问题,信号的频率相当低。 仅在有(单个)发送响应时。 我自己倾向于#1。
大约 6 年之前 回复



如果您要进行RESTful操作,则当客户端请求 HTTP GET myserver.com/data </ code>时, 服务器应返回 202接受的</ code> 状态码:</ p >


202已接受</ p>

该请求已被接受处理,但处理尚未完成。</ strong> 该请求最终可能会执行,也可能不会最终执行,因为在实际进行处理时可能会不允许该请求。 无法从这样的异步操作中重新发送状态代码。</ p>

202的响应是故意不提交的。 其目的是允许服务器接受对某些其他进程的请求(也许是每天仅运行一次的面向批处理的进程),而无需用户代理与服务器的连接一直持续到该进程完成为止。 随此响应返回的实体应包括请求当前状态的指示,以及指向状态监视器的指针或用户何时可以期望完成请求的一些估计。</ strong> </ p>
</ blockquote>

Python服务器可以将ETA和URL返回到临时资源,以请求操作的当前状态(例如: myserver.com/temp_data?processing_status </ code>)。 然后,由Go客户端通过请求此资源并读取ETA来等待任务完成。 处理完成后,Python服务器可能会返回 410 Gone </ code>状态以及新资源的确定URL。</ p>
</ div>

展开原文

原文

If you want to do it RESTful, then when the client requests HTTP GET myserver.com/data the server should return a 202 Accepted status code:

202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

The Python server could return an ETA and an URL to a temporary resource to request the current status of the operation (e.g.: myserver.com/temp_data?processing_status). Then it's up to the Go client to wait for the task to fulfill by requesting this resource and reading the ETA. Once the processing is done, the Python server could return a 410 Gone status with the definitive URL of the new resource.

duanjia4220
duanjia4220 -这是一种非常好的建议/推荐的方法。 但是,它需要Go服务器以一定的时间间隔不断轮询Python服务器。 我想避免这种情况,因此不想走这条路。 除此之外,这还需要我有一个相当异步的python服务器才能实现这一点,并且像模型这样的单线程是行不通的。 那就是分派任务,然后以异步方式发送202。 我想避免的事情。 我可能会这样做,但是会倾向于使用非轮询方法。 好点,虽然。 我会记住的。
大约 6 年之前 回复
Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问