Justin Cormack sparks a discussion about the adoption of RESTful architectures in the enterprise or the lack thereof with his post.
… 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.
As he explains the role of resources in the enterprise, he points to the statistic that 9 out of 20 [developers] prefer to use REST [as] it is more productive. He alludes to the simplicity of using a REST based API as opposed to generating proxies from service contracts and schemas (wsdl, xsd) of services, which may or may not be built on WS-* standards.
It does not involve programs to generate huge chunks of useless code. It involves hypertext (HATEOS) not opaque documents that are mappings of database schemas.
He continues to explain the idea of resources in the enterprise with an example of how one might model a typical customer in a CRM system.
What are the resources in the enterprise? Start with customers. A CRM system is a clear example of something that needs to be modeled as resources. 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.
According to this article, which talks about ROE (Resource oriented enterprise), every enterprise has silos of data; silos that satisfy different business functions, payroll, HR etc. and there are benefits to thinking of the data these silos represent, as addressable resources. Benefits in terms of cost as well as opening up these islands of data than can then be used to drive informed business decisions.
… what the ROE asks for, they must further open themselves. Not primarily in a technical sense, but by offering better abstractions of their information content. In the Resource Oriented Enterprise, this is clearly achieved by integrating them into the URI-based addressing scheme.
According to Justin, its not hard to do this.
Building this framework can be incremental. You need either tools that already provide REST APIs, which is becoming easier, or a web application development framework. This is the convergence point between application frameworks and web content management.
In addition to the benefits of moving towards an ROE he mentions in his post, he also aggregates some of the responses from the REST mailing list.
[it] makes things human browsable, and declarative makes them computer browsable […] Business logic becomes content rather than data, rather than there being tables of parameters that the business logic black box feeds off, the states themselves become resources that can be discovered, addressed, and reasoned with.
Introducing REST to the enterprise […] help[s] the enterprise leverage the agility of the web architecture, and to make building new enterprise applications cheaper and easier.
the use of REST brings the decentralization aspects of the Web into the enterprise world and allows designers and developers of networked systems to create and evolve their components without the resource and time consuming effort of bringing them into a single room to discuss APIs. [Jan Algermissen from the rest-discuss mailing list]
I believe that REST’s use of hypermedia […] make maintenance, deployment and versioning much easier, which translates to lower costs to the business in the maintenance phase of an application. [Darrel Miller from the rest-discuss mailing list]
Also, […]interoperability is much easier to achieve with REST because the ubiquity of HTTP. This has a huge positive side-effect for integration as well. My gut tells me that SOA Governance could really reap the benefits of a RESTful architecture as well, but I don’t have any details yet on how. [Bill Burke from the rest-discuss mailing list]
Justin highlights Benjamin Carlyle’s observation that you can view REST as an evolution of SOA, as better and easier to consume services. Are we seeing a shift in the emphasis from service orientation towards adoption of RESTful approaches in the enterprise? or is this a natural evolution like Benjamin suggests?