Enough of RESTless SOA? Speak now or forever hold your peace
Speak now or forever hold your peace...
Has anyone ever actually heard someone disrupt a wedding ceremony by voicing an objection to the proposed union?
Has anyone ever heard someone object to an SOA plan because its based on SOAP, and not enough REST?
In an interesting new post, Justin Cormack says not enough people speak up when corporate decisions are made to adopt of SOAP-base Web services as the foundation of SOA, before the deal is sealed and things really start to get messy:
"I went to a meeting a while back with a company starting to move to a Web service based, internal API based architecture, and there was a minute where the CTO said (more or less) “does anyone know of any let or hindrance to this being a SOAP API?”. Like those moments at weddings, no one spoke out. But I do object. SOAP is not the backbone of a happy architecture, but we do not have the strength to say no right now."
Justin says this is the time for enterprises to move from SOAP to REST, and transition their service oriented architecture (SOA) to a resource oriented architecture (ROA).
Not a bad nomenclature -- and he makes his case for a RESTful ROA:
- Web developers favor REST. "It is more productive. It does not involve programs to generate huge chunks of useless code. It involves hypertext, not opaque documents that are mappings of database schemas."
- REST is less expensive, as it requires fewer application development resources.
Look at modeling systems as resources, Justin continues. "Resources are much easier to work with than services, as they share uniform semantics, and they are addressable, two keys to making application design simple." A CRM system is an example of something that needs to be modeled as resources, he says. "You need API calls that can find products a customer has bought, support tickets, all the core data that you would need to build customer service portals, internal support applications."
REST enables a resource oriented architecture based on HATEOS or Hypertext as the Engine of Application State. HATEOS "involves is moving the vague and very expensive field of business logic from code (often code that is not even owned or understood by the enterprise, as it has been embodied into code written into systems from suppliers) into hypertext documents," Justin explains.
Thanks to Dilip Krishnan for pointing to this post.