In my experience the successful application of the RESTful architectural style to any given software integration opportunity, requires an appreciation of the levels of RESTfulness gained from the relative levels of effort expended. I will attempt to explain my interpretation of these and identify where I see positive an negative implications:
The approach where the interactions between agents are ‘designed’ as resource-oriented, based on a finite set of well-defined methods analagous to the RFC2616/HTTP ‘verbs’, or more generally a CRUD scheme. This kind of approach achieves common-ground in the design-space, but is not followed-through with a strict adherence to the RFC2616/HTTP protocol as a framework for implementation, possibly using a proprietary xDBC stack, language-specific binary protocol or heavy SOAP stack. As such we see a logical resource-oriented perspective but with none of the true benefits truly embracing the web as a foundation.
- Achieve uniformity in resource/interface design.
- Establish a common inter-domain design philosophy.
- Not addressing the heterogeneous middleware friction.
- Stopping short of realising the full value of REST.
- Little or no departure from traditional CRUD data-access.
This is possibly the most common category where a Logical REST design is implemented within a RFC2616/HTTP framework, exposing concrete resource addresses on well-defined http URI’s in a web-compatible manner. However, the cosmetic dimension relates to the fact that these RESTful endpoints are thin, ‘cosmetic’ wrappers over traditional RPC oriented service endpoints, effectively acting as proxies. As such Cosmetic REST is of benefit to clients who have less intellectual and technical friction in consuming a service, but do little to thin-out the general integration sprawl within the domain of the service-provider. As such the addition of public RESTful to private RESTless bridging increases the integration burden of the provider.
- Creation of real RESTful service endpoints removing technical friction from clients when consuming service.
- Unhook clients from internal integration dependencies by providing a uniform, intuituve interface.
- Increases the integration burden of the provider.
- New facade on existing brittle integration points.
- No increase in productivity gained from supporting simplified exposure.
This approach is a full application of the architectural style in a deeper sense than the cosmetic use of the HTTP protocol in exposing interfaces. Resource oriented design of a system is a significant departure from simply exposing functionality or information services from a complex machine using some arbitrary exposure/protocol dialect. Instead resource orientation inverts the ‘functional’ exposure of traditional RPC styles of integration by facilitating an information-first (not functionality first) interaction between a client and a system. In simple terms your interaction with a true RESTful system is through the manipulation of these resources, where creation, updating or deletion of resources or resource-atributes has explicit (or implicit) behaioural contracts which will conclude within a stateless atomic context. This completely decouples a client from the internal workings, dialects, processes, etc of a traditional approach to opening out the functions within a ‘RESTless’ system not based on the resource orientated architectural style.
- Cleaner relationship between RESTful exposure and implementation of underlying system.
- Reduces the ‘thickness’ of interation logic sitting between the network addressable endpoint and the implementation.
- Integrate clients with your information and not your process and/or functional granularity.
- Despite the RESTful or resource-oriented architetural style being synonymous with the web, it is still perceived as a ‘new approach’ in the context of internal enterprise business systems.
- A more significant mind-shift is required before this appreciated
- Still little hard evidence of the positive implications of resource orientation over traditional approachs – it just ‘feels’ like the right thing to do.
In my experience to date, for anything other than a green-field web-application which may go directly to a Fundamental REST approach, the larger integration challenges associated with service enablement of a more complex enterprise or enterprise system will ultimately start life, as we have, in a Cosmetic RESTful approach – most likely resulting from the combination unmovable silo’s of historical investment, as well as the limited impact of a Cosmetic or Facade based approach when breaking new ground. In such cases the cost-effectiveness of REST and resource-orientation do become hamstrung, purely because to exploit REST you have to build more layers of mediation initially…until the confidence in REST increases to a point at which true, or more Fundamental REST can be driven from the edge of the enterprise, down into the silos.