As Service Oriented Architecture is becoming more and mainstream and enterprises start reaping the benefits of implementing them, there is a general trend in SOA implementation that each and every functionality be exposed as web service (read SOAP based service).
Many enterprises and external facing web sites have started following this and getting trapped into unduly excessive larger time to market and in turn losing business opportunities to competitors or else joining another failed SOA initiative.
If you happen to be part of team implementing SOA or following trends in web services implementation, surely you would have come across terms like Service Contracts, Policies, Web Services standards like WS* specifications–> WS- Reliable Messaging; WS-Security; WS-Interoperability; WS- Transaction; WS-policy; Service Discovery, Service registry, Service Governance, Service Versioning, SOAP message structure (header/body/faults), SOAP Protocols, XML Schema, etc..etc.
Each of the above term is quiet heavy and adds to complexity in rolling out web services based large SOA initiatives, however successfully dealing with these complexities fetches several benefits though.
To realize the Enterprise SOA vision and in turn expose functionality as services, does each one of the initiative have to go through this pain of dealing with so many complexities?
Probably not, and hence to address some of these complexities in web services implementation, there is a new style of web services architecture called REST (Representational State Transfer).
Representational State Transfer (REST) is an architectural style of building services on World Wide Web (WWW). It does so by leveraging the existing WWW architecture(http being backbone) which provides a way to navigate through web of resources like URLs, static or dynamic pages, Files, images, videos, and so on. REST logically organizes these resources and expose them through URIs to be consumed by external world. REST is a way or style to design services to be exposed in this manner. It is not proprietary to Java or .Net or any other technology or platform.
Some analyst address REST as simple XML without SOAP.
Before we dwell deep in to REST principles, let us revisit the key tenets of SOA
1. Boundaries are Explicit
2. Services are Autonomous
3. Services share schema and contract, not class
4. Service compatibility is determined based on policy
On the similar lines, REST based services are to built by using certain fundamental principles as below
1.Every Resource that merits being identified should be identified by Unique Id; it should be noun and not verb. To model REST based services, Map URIs to resource which may or may not represent application logic.
e.g. http://ibuy.com/Order/1234 identifies Order with an order id 1234. Order details like for which customer, list of products, total amount etc. can be captured as part of content of the document. Customer, product are also potential resource and can also be uniquely identified using URIs.
2. Once URIs are identified for a resource, Use these id’s or URIs to link them together
A customer placed sample Order is depicted as follows
<Order ref =”http://ibuy.com/order/1234”/>
<amount> 15000 </amount>
<product ref= “http://ibuy.com/product/455” />
<customer ref =”http://ibuy.com/customer/20084 />
3. Http methods are means to interact with these URIs
Use Standard http methods like GET (Read), POST (Create or Append), PUT (Update), DELETE (delete) to operate on these identified resources. These are the only verbs or methods/operations available in REST world as against many operations available under service in SOAP world.
Following is the mapping of SOAP operations to REST methods
|ManageOrder SOAP Operations||ManageOrder REST Operations|
|GetOrder (OrderId string)||GET|
|InsertOrder (OrderObj Object)||POST|
|DeleteOrder (OrderId string)||DELETE|
Resources are updated by sending the updated document or XML to the URL.
E.g. In RESTful system an Order will be updated by submitting the updated Order XML or document at the respective URI.
4. Allow multiple representation for same resource
Same Order can be represented in XML, Word Document, PDF, (X) HTML, JSON, ATOM and in various other formats.
5.Communication with Resource should be always stateless, if needed implement transactions through resource organization.
E.g. Save Checked out basket as resource and provide the Resource URL.
With the ground covered so far, by now certainly there are questions popping up, how can it deal with the complexities of business operations? Can it handle Transactions, Message Reliability, and Security; can it be used to build interoperable system, are organizations implementing REST? Is it main stream? Etc. Etc.
While I will try to deal with some of these over next a few blogs, here are some starters.
Google, photo site flickr, Yahoo services, and several other social sites like Facebook are built using REST based services. Amazon and ebay provides both SOAP and REST based services.
One word of caution though, REST will not completely replace SOAP Services, nor it is intended to, but some scenarios would definitely be easily addressed through REST than SOAP based Services. In other words REST can definitely start resting SOAP in some enterprise scenarios.
Before i conclude, a word on vendor support, REST is supported by almost all the top vendors including Microsoft through its Windows Communication Foundation (WCF) as part of .Net 3.5 framework. MS also provides REST services template through REST starter kit , quiet helpful in getting started.