Multiplexing is a pretty cool feature of http/2. It allows using one connection to serve multiple requests from a single client simultaneously.
My question is: does this multiplexing feature violate REST API rules?
- I understand that REST API enforces request-response architecture, but multiplexing without server-push (streaming) feature enabled is essentially one request -> one response paradigm, so that’s not a violation, is that right?
- REST API also enforces stateless, and I’m lost there: is multiplexing through a single connection considered as stateful or stateless?
If I want to upgrade a REST API which is currently implemented with HTTP/1.1 to use HTTP/2, do I have the privilege to use the multiplexing feature, or I have to do stream after stream (req1, res1, req2, res2…)?
>Solution :
Network multiplexing and REST API are two absolutely different matters/layers of responsibility.
Multiplexing is about how do communication signals flow, and not about what is the architectural pattern of HTTP messages’ communication (which is what REST is all about).
From the REST perspective, it does not matter:
- whether you maintain a single physical (TCP) connection throughout several request-response cycles;
- you open and close TCP connection per each HTTP request-response, or
- even if you use something else than TCP (yes, that’s not a good idea, but theoretically, as long as communication is ensured to have integrity, consistency and stability (which is all TCP brings), it doesn’t much matter how the physical connection is established).
REST is an architectural (design of the web application) pattern for implementing web applications.
So, one (Multiplexing) is how the physical connection is established, and another (REST) is how you design your web application. As long as HTTP messages flow seamlessly, there is nothing in multiplexing, that can violate anything in REST. Again: these two serve different purposes.