Making sense of REST in context with SOA

I continue to spend a lot of time thinking and researching REST — REpresentational State Transfer. Yes, REST is a set of architectural guidelines introduced by Roy Fielding in his dissertation where he defined HTTP. While I couldn’t find a link to Fielding’s disseration, I did find a very good blog entry written by Fielding.

Given its origins, REST follows the philosophy of HTTP. In other words, you give everything an ID, you link these services or components together though some standards methods.  These services communicate in a stateless manner.  In addition, these resources can be used in many different contexts.  What is very important about rest is this idea of linking resources based on self-describing interaction where there is no state between requests. Therefore, from a customer perspective it offers the fast, effective model for development that is fundamental to being able to make organizations more fluid and effective.

As part of my research, I had an interesting conversation with Martin Nally,  IBM Rational’s CTO  about REST, its value and its relationship to SOA. From his perspective, REST looks like a data set that is exposed with Internet protocols.  And if you look at the way REST is described in terms of GET, PUT, POST, and DELETE.  In Nally view, REST provides “a simple style of using HTTP if you can look at your problem set as a web of interconnected hyperlinked resources.”  I thought that Nally put it very well, “In the old days we would create a data model with a representation of department, employee, etc. to create the data in a database. Then we would write two styles of applications: one that was basically to conduct simple data based operations (Create, Read, Update, Delete) and a second to type of application that would apply that information to business process — how do you rate a customer’s credit worthiness?”  In other words, it is necessary to intermix web based services that are stateless and can link data together across a distributed computing environment combined with well defined business services that encapsulate business rules and process. In the operational environment based on business services — based on a Service Oriented Architecture — there are many resources provided based on components that require a lot more structuring of process and more overall governance.  For many types of implementations, there needs to be the foundation of technology concepts such as a registry/repository for both management and governance.  There needs to be a transport mechanism for guarenteed transactions.

I think that we need to look at both two world views — REST to support the web, data oriented linkage style with the structured world of  a services and process based approach.  Let’s leave the religious wars to someone else and recognize that there is room in our complicated software world for both.