Post-REST
Problems with these assumptions:<p>- QUIC. Yes, it&#x27;s UDP, so its connections don&#x27;t behave the way TCP ones do, but it&#x27;s still based on IP and UDP connections, so it still breaks down under a number of circumstances (rotating backends, mobile clients changing connection types, firewalls&#x2F;proxies, etc)<p>- HTTP-based. If you use HTTP, you must accept its warts, like being stateless. Even considering a transport protocol that can multiplex connections, you still need to track all these individual stateless calls. Perhaps a protocol that took care of state might give you some benefits (such as workflowing?)<p>- Workflow orchestration is just distributed centralized state machines. It shouldn&#x27;t have much to do with a replacement for REST, because the API isn&#x27;t necessarily controlling a state machine, and the API (in this case HTTP) isn&#x27;t stateful anyway...<p>Why don&#x27;t we evolve APIs into a sort of language? Why make 4 separate requests (PUT this, GET that, munge it, POST a result, GET to confirm) when you know exactly what you want to do? We can instead build a language or spec where we can shove a variety of instructions (even a &quot;workflow&quot;) into a request, let the backend handle the method of accomplishing it for us, and retrieve the result. This can be extended throughout microservice architectures.<p>The transport protocol is a separate issue. So you want lower latency, and you want less round trips, and you want to survive network interrupt. Design a transport protocol for that (QUIC is a good base). If you want it to survive even more interruption and allow clients to split networks, start looking at intelligent tunnels with advanced routing mechanisms and spread them along the path. But that&#x27;s a lot more funky than simply replacing TCP.