One of the things that I love of the software development trait is how fast things change. We are in a never stopping stream of new ideas, changing paradigms; the essence of pure innovation.
However, once in a while we look back to old dusty corners of what we used to do and believe and find out that those old forgotten ideas taken from mistaken were actually right all the time. Such is the case for REST architecture, a pretty old idea that fell into oblivion just to become the new trendy buzzword a couple of decades later.
Just for historical context; REST architecture was created along with the HTTP specification almost 20 years ago. The idea behind REST is to provide access to resources via an URI, each URI returns the resource representation on a different state, part of the data retrieved from each step contains the means (links) to access a different resource's state (sounds pretty familiar when explained in that way, doesn't it). If you haven’t heard of REST until recently that’s probably because the term was not coined until 2000 by Roy Fielding who was part of the team that came up with the HTTP 1.0 and 1.1 specification, cofounder of the Apache HTTP project and board member of Apache Foundation.
REST services have recently been brought back into the trendy stage. I personally believe that this sudden revived attention has happened due to two facts:
- The ubiquitous presence of JSON in web applications grants to developers a simple data format that is not only JavaScript native but that is also tied to the HTTP protocol which is the vital breath of the web. With that in the picture and the recent (like 10 years recent) hype in SOA applications this seems like a solid option.
- People are just sick of trying to implement over-complex and verbose SOAP based services ("Simple Object Access Protocol" is more like a sarcastic name for it ) for simple CRUD non-document based applications where tight security is not a CTQ nor is distributed computing and most of them fall into that category.
However with the hype normally comes the confusion. I have seen a lot of applications that claim to be RESTful just because they user JSON request/responses strings. Allow me to explain why I don’t agree with that.
REST web services stand over two main principles or rules:
- Decoupling through SOA
- Hypertext driven interactions (HATEOAS)
Decoupling through SOA and Hypertext driven interactions
One of the key points of SOA applications in general is to reduce coupling. SOA is intended so that huge applications can be chopped into smaller specialized distributed entities or services that can work together as a whole so that they can be designed, developed, supported, maintained a hosted in a more sustainable and efficient way.
Each of these services can be built with the technology that better fits the specific needs of each one. This services need to provide some way for the clients to know what they can do and how to do it (decoupling). As SOAP relies WSDL or WADL so REST relies entirely on the hypertext data returned on the responses to client requests. A RESTful service must provide the client with all the means of interaction (URLs or how to build them) in order to comply with de expected decoupling. If your REST services require for the client to have certain insight of how your application works beyond a basic knowledge of the exposed resources and the initial URI, or if the services are not using the HTTP native methods to interact with the resources exposed then that is some weird RPC with JSON, not RESTful services (I’m not implying that RPC is bad or inferior, but its definitively not REST).
Another critical difference between REST and RPC/SOAP; REST leverages on the already existent CRUD HTTP methods (PUT, POST, GET, DELETE, INFO, TRACE, OPTIONS, HEAD and CONNECT) while RPC/SOAP services define their own interactions (verbs). RESTful web services also base the entire interaction in the hypertext received as part of the response (hypertext being XML, JSON , YAML or whatever data representation supported by HTTP ), in contrast SOAP is in fact an XML based protocol so it is not tied to HTTP as REST is (This last claim is debatable, though).
SOAP is still the W3C standard king by all means for all related to web services, it’s a robust protocol (with a ton of features like WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, WS-RemotePortlets… not simple, definitively not simple at all… unless you compare it to CORBA) ideal for B2B interactions and distributed environments.
For more simple services REST is a simple yet solid option worth trying but must of all worth doing it the correct way.
Comments
Post a Comment