On Fri, May 1, 2015 at 2:23 AM, Tom Arnfeld <t...@duedil.com> wrote: > Q: Could you explain in a little detail why the decision was made to use a > single HTTP endpoint rather than something like */event* (for the stream) > and */call* for making calls? It seems a little strange / contrived to me > that the difference between sending data to the master and receiving a > stream of events would be based on the order of the calls and via the same > endpoint. For example, would there not be a failure case here where the > initial HTTP connection (*SUBSCRIBE*) fails (perhaps due to application > error) and the driver continue making subsequent POST requests to send > messages? In this situation, what would happen? Would the next http request > that sent a message start getting streamed events in the response? >
The initial design did include two endpoints (/call and /events) but we decided to merge them into single endpoint for a few reasons: --> With the two endpoints design, the SUBSCRIBE "call" had to go to the "/events" endpoint whereas all the other calls had to go to the "/call" endpoint. This is because all the other calls to "/call" elicited a "202 Accepted" and having SUBSCRIBE be the only call on "/call" that elicits a "200 OK with framework id in the body" was weird. Also, it was unintuitive when looking at the protobufs in scheduler.proto. --> More importantly, having two different HTTP end points did nothing to tell the client (scheduler) that it has to use two different connections. Note that a scheduler could have very well used a single connection to talk to two different http endpoints on the master, if it didn't know better. --> Most HTTP clients (that I looked at) default to using a different connection with each request anyway to avoid pipelining and head of line blocking issues. So programming against a single endpoint should be friendly. --> Note that irrespective of whether it is a single endpoint or two endpoints, the client has to make sure that it first SUBSCRIBEs before it makes any other calls; otherwise master will return "403 Forbidden". Only the SUBSCRIBE call will get a streaming response. --> Having a single endpoint lends itself to easily support HTTP/2 and websockets in the future because they support multiplexing on a single endpoint/connection. HTH,
