HTTP is just a way to communicate state - a protocol that _can_ be used for implementing the architectural style. Unfortunately, most of the rant is about HTTP.

HTTP is just a way to communicate state - a protocol that _can_ be used for implementing the architectural style. Unfortunately, most of the rant is about HTTP. Once you see HTTP just as one example of a more abstract way to interact in a client-server model, your focus will shift towards the more important topic: semantic formats that represent state, formats that make it easy to write clients against. And if you do it right, you build a vocabulary that represents your domains. A good format to start with is JSON-LD. But please don't just describe the entities of your business domain. You have to describe semantics of how the client can interact with the server and change state (like links, actions, feeds). And if you build a business around it, put these semantics / vocabularies at a central place - build something like https://schema.org https://schema.org for your own corporation. Then use HTTP for communication and building out your systems. And it will be more robust, flexible and scalable than anything built on SOAP.