REST-style architecture in the real world

A couple of weeks ago, I presented REST to the IT staff in the London division of a major US investment bank. Out of something like 100 people, only a small number of people had ever heard of REST. Yet this bank had invested in a REST to SOAP bridge to facilitate delivering product and market information over the web. Surprisingly, many people are building REST applications in business and aren’t even aware of it. In doing research for the presentation to the bank, I received some advice from someone at a large pharmaceutical company on how he describes REST for people who have never heard of it. The term Representation State Transfer is extremely off putting. He describes it as Web Oriented Architecture rather than Service Oriented Architecture. By making everything a URL (although technically a URI), you can access everything via that URL and use standard web commands like Get and Post to access and update those things, something we call resources. This URL-based update of information contrasts with a very Remote Procedure Call-like interface of SOAP. Basically, every time you access information in a browser or a pop-up in a mashup receives or updates information, you are using REST. I tried describing it this way and generally people get it.

However, trying to find people using REST-style architecture as examples for the investment bank was not easy. How do you put REST into practice aside from making a browser application? What examples are there in enterprises as opposed to the general internet? Examples in Web 2.0 and the web in general abound with Amazon being one of the earliest examples of an open REST interface, but not in the enterprise.

Ultimately I found some examples and it was fascinating and informative. Unfortunately, nobody wants to let them use their name anymore, especially banks or pharmaceuticals. They only allow me to say “large pharmaceutical” or “large retail bank” and not their company’s name. If you are interested, post a comment and I will try to get you in touch with these people.

The first example was a large retail bank based in California who used REST in constructing their loan processing system. Having looked at SOAP, the architects of the system decided that they got very little additional benefit over ordinary HTTP calls and started constructing a distributed application using GET and POST. They constructed URIs around classes of objects like Customer, Loan and Account, which becomes their resources in REST terminology. Since the application was inside the firewall, security was controlled through restricting IP addresses around URIs. The application itself has proven to be very scalable since this is a major lender in the Western US.

Without realizing it, this bank had constructed an application using REST-style architecture. The application at this retail bank is very similar to an example created by Joe Gregorio, who has been very active in the REST and Atom Publishing communities. The Day Trader application is an example application created by IBM to demonstrate how to develop J2EE applications and is now part of the Apache Geronimo project. Joe demonstrated that this J2EE application could be built using REST-style architecture complete with transaction control.

The second example is at a large pharmaceutical company where they are experimenting with providing universal content access from various content and records repositories. By making all content URI-addressable, it makes it possible to also address the policies and metadata for that content. Using one consistent interface and a simple web call, they can set the policy of a piece of content without caring what the underlying system managing it is. Of course, there is hard work there in that something has to interpret that HTTP PUT on the URI. In addition, a consistent URI access means that they can provide a uniform, aggregated search across all of their content stores and access the results consistently using a URL.

The third example I discussed was a large insurance company that has been debating REST internally for a while now. To this company, any well-structured business message, such as FIX, Swift or any defined XML message, belongs in the realm of SOAP applications. In addition, any applications that require tight security should also use SOAP. The enterprise architect I spoke to is a big advocate of using XACML in conjunction with web services to control access to services. However, he believes that content-oriented applications are very applicable to REST since the information is loosely structured and does not easily fit into the procedural interfaces of SOAP. In addition, any application that is internet-based and has low security requirements is best implemented in REST, since REST is the architecture of the internet.

One thing that all three example companies have in common is resistance to REST since it is new, at least to IT management. The issue is not necessarily any technical issues, but a lack of understanding of what REST is and how it differs from SOAP. With billions of dollars of investment in industry in SOAP, once that understanding sets in, that’s when the arguments will become technical. However, REST has proven itself to be simple, flexible and extremely scalable.

There had been some nervousness about me even presenting the topic of an alternative to SOAP and SOA at the investment bank where I can safely say that they had invested at least tens of millions of dollars in SOAP-based applications and infrastructure. At the end of my presentation at the investment bank, one of the participants asked me where I thought REST could be applied. My answer was not to throw out the investment that they had made, but put it in areas where SOAP had not gone so far. Content applications is a safe area to invest where most applications are native Java or .NET and REST provides a convenient bridge between those worlds and easier content streaming than SOAP. In addition, they must invest in REST in their web site to help bring Web 2.0 features like mashups into their web sites user experience. This is an area that cannot wait.

My answers dispelled their concern and I think it opened up new ways of looking at the information in their IT systems and how can they provide it to their employees and their clients and customers. REST has made huge in-roads in Web 2.0, but is only beginning in the enterprise. However, some simple baby steps are possible and can yield rewards in simplicity, performance and scalability. And you may not even know you are using REST.