One common challenge that enterprises are facing today is “How to RESTi-fy their decade old legacy applications”. Before we get into “How” part of RESTifying enterprise legacy, it is important to first understand the “Why”. What is wrong with SOAP web services? What actually changed in recent years, that we need to rethink now? After all, web services have abstracted enterprise legacy for more than a decade now.

Following are few broad areas that we need to understand why REST is more prominent than ever.

1) REST as an Architectural Style Makes More Sense in Certain Situations

We tend to compare REST with SOAP web services but there cannot be a direct comparison between an architectural style (REST) and a protocol (SOAP). SOA with SOAP/HTTP and ROA (resource-oriented architecture) with JSON/HTTP have become so prominent forms of these two architectural styles that we mix these terms up. More apt comparison is between SOA and ROA. I have, though, used JSON and SOAP to examplify scenerios in the remaining post.

With that distinction in mind, let us start with SOA based web services. Web services are a way to do RPC. In simple terms, what RPC means is that if you cut open the SOAP request message, it has operation name inside it. Remember that “P” in RPC stands for “procedure” that you intend to call remotely - using web services, CORBA or any other means. This operation-oriented nature has problems in certain situations. It assumes that there exists a predefined operation, which behaves in certain way. Provider creates the contract and consumer adheres to that contract. This rigidity in contract though has benefits, is not always needed. Rigidity demands more governance and complicates the usage of services beyond enterprise boundaries. This behavior, to large extent, is dictated by SOA principles. Discoverability, service contracts, abstractions etc are, afterall, core to SOA. It does not mean that REST based architecture gives us the freedom to do things the way we want. It too has design principles and “constraints”. However, there are certain differences:

• Both approaches decompose the problem domain differently. REST breaks down the problem as resources, where as SOA puts actions on the front seat.
• For most practical purposes, REST sits atop HTTP, whereas SOA based web services have one extra layer of abstraction in addition to HTTP - SOAP. Do we really need it, is highly debatable. It does have merits but those may not be needed in every situation.
• In case of REST, both “Web applications” and “Services” are designed with same architecture. It leverages standard elements of internet (routers, proxies, servers or consumer platforms) to their full potential, without any customizations.

Irrespective of which architectural style we use, we need to make right engineering compromises and adhere to the guidance to the extent needed. What is more important is to understand the rationale, and make wise use of guidance, stated principles and imposed constraints for architectural style chosen.

NOTE: There do exists message-oriented style for web services (Example: document/literal wrapped) but that too have constraints in addition to the complexity it brings.

2) Advent of Digital Technology

Usage of REST has increased manifold due to emerging digital technologies. Let us take example of lowest denominator of digital channels – a modern web browser. It is not long since the job of a browser was primarily to render html markup. Of-course browsers were interactive right from the early days but most of the interactive-ness was handled on the web server. Browser mostly displayed content and captured the input. Web servers called the middleware, which in turn abstracted various enterprise systems. Things changed as commodity hardware became cheaper and powerful. It allowed desktop applications including browsers to consume more hardware and network resources. JS based frameworks, libraries and developer ecosystem leapfrogged the web development. Browser became full-blown client tier that now could provide rich user interface and also invoke enterprise resources directly.

With these advancements, REST based services made much more sense than the SOAP services. Roy Fielding’s REST architectural style that was envisioned for World Wide Web became more relevant to manage both html templates as well as the data to fill those templates.

Extend this to mobile and other devices that have built in support for JSON, it makes perfect sense to use REST based architecture that provides uniform access to channels – existing or new.

3) Web APIs is a Channel Strategy

It is important to note that REST based web APIs are mostly part of channel strategy whereas SOA has traditionally been used for enterprise integration. Yes, APIs can be used to wire enterprise applications, or web services can be exposed for digital channels but there is fundamental difference between the two. Channels typically require data to be mashed together which is easier if based on resources than on verb-based services.

Also, APIs are about openness and innovation beyond enterprise boundaries. This require lean-ness in governance, ease of discoverability and so on. The way we have been governing web services, cannot meet that expectation.

4) Performance and Scalability

Verboseness of XML increases consumption of computational and network resources. This become more important when applications are chattier. Chattiness is the very nature of the digital applications where user experience takes the centerstage. We need smaller payloads but with more network communication. Also, REST uses “GET” heavily (and SOAP does not) which is HTTP cacheable. Other aspect around performance that is usually discussed is stateless-ness of REST. In my opinion, SOAP services too are (or can be) stateless which makes this argument a little weaker. The only difference is that statelessness is explicitly avoided by REST.

Having established when and why REST is advantageous, let us see how this can be implemented in enterprises.

There are two situations are typically encountered in organizations.

• Ground up development of application
• Legacy systems that need to be exposed for digital consumption

Let us discuss these two cases in detail.

Ground-up Development:

This is most straightforward and top-down scenerio where services can be designed RESTful ground up. We define the API spec first and then create the implementation. How we design REST APIs is not scope of this post but I like this and this as starting point. Three fundamental rules in my experience, are i) APIs are not mere CRUD operations over HTTP. ii) Granularity of API is contextual to the problem domain. iii) It is okay to convert some “Verbs” as “Nouns” as long as we have enterprise-wide formal guidance that describes where to draw the line.

Legacy systems that need to be exposed to digital consumption:

In large enterprises, there are tons of legacy applications (e.g. mainframes based, client server or fifteen years old java based applications) that are core to the business. Re-engineering these applications just for RESTification is not always business justifiable. Digital initiatives, however, do provide opportunities to piggy-back the RESTification exercise. It is important to note that digital platforms by themselves do not necessitate usage of REST architecture. There is affinity towards JSON based payloads which can be achieved without REST. In fact, organizations in last few years have chosen to create JSON service wrappers (over existing web services etc) to meet needs of mobile and other RIA platforms.

Assuming that benefits of REST usage are well justfied (some discussed above), following is an approach that can be considered. Here, I also like to mention Richardson Maturity Model for REST strategy. In my opinion, in large enterprises it can take years to jump from one maturity level to the next as prescribed in this (or my understanding of it..). It may be more beneficial to seggregate API layer from the underlying systems as described below (in progress).

Step-1: Identify the resources from the legacy systems. These could be extracted from existing documentation or code. It is comparatively easy to identify resources from applications that are built on object-oriented design. Besides resource identification, we need to determine the relationship among the resources.

Step-2: Once we have identify the resources, next comes the ownership. Though resource identification and their ownership can go hand in hand, It is important to understand that just because a resource is found in an LOB application, does not mean it belongs there(Example: A “Customer” resource in a multi-LOB organization). And vice versa. In addition, there can be resource hierarchy that needs to be established.

This leads to discussion on where we start with REST in organizations. In an ideal situation, it should enterprise wide initiative. At the bare minimum, the guidance and enterprise-wide governace aspects must be chalked out upfront.

Step-3: For the identified resources, we now need to map existing service operations to HTTP verbs. This is the most complex part of this exercise. We may end up creating new resources or “blend resources” in the process.

Step-4: Formalize the API specification. While performing above three steps, we are essentially modelling our APIs from the existing implementation in a bottom-up way. Extracting a formal definition of API is needed so that it can be shared with the API consumers.

Step-5: Once we have the API specification with resources and verbs defined, next comes the implementation of API layer. API implementation in this case merely means to create layer that expose an endpoint as per the API spec and wire it with existing underlying resources. Commercial API Lifecycle management suites can ease this work. Most of these products also support industry specifications for APIs, provided lifecycle management services and add other digital capabilities. It however is not necessary to use any commerical tool to wire API layer with enterprise legacy resources. Whether to use one or create a custom API layer will be discussed in another post.

Feel free to comment.