Okay, I had been hearing a lot about REST lately, not really knowing what it was. Seemed like standard web stuff for me, lots of talks about HTTP verbs, post and get and that kind of things. So I wonder was what was new in the whole idea? I therefore decided to educate myself a bit and started with listening to this podcast of Software Engineering Radio: Stephen Tilkov on REST
So indeed there is a lot about just standard, existing web standards in REST, and this is what somehow makes it powerful. The new idea is to use standard web techniques to perform inter-communications between systems, in a SOA fashion. I won't enter into technical details and explanation on how REST works, first of all because I am not an expert at all and secondly because there is already plenty of documentation out there on the cloud. I would advise you listen to the podcast for a start if you are completely new on the subject. And good thing about this podcast is that the speaker is coming from the web services world and moved later to REST, he therefore has a good idea of the differences and pro and cons of both techniques.
My intent in this post is to try to analyze what REST means, where it apparently fits in the web and SOA world and what may o may not the proper scenarios to use it. I will do that in a very humble way, dropping my first thoughts on the matter. I may be missing important points and be inaccurate on some others so all comments are very much welcomed!
At first REST appears like a simplification of web services, SOAP and WSDL technologies to remotely connect systems in a system implementation technology independent fashion; there is obviously a technology common point in it and that's happening at the transport and protocol level, but internal technology used to implement the communicating systems can be anything as long as it is providing REST end points. I remember when in the past I was using DCOM to connect systems, thinking that such component technologies like DCOM or CORBA where the proper way to make distributed systems communicate and the de-facto standard (or multiple-standards I must say as they are not technology agnostics). I remembered then when I first heard about web services and SOAP and thought: hey what's that!! we have great, complex technologies like DCOM or similar (by the way I Loved COM...) to interconnect systems, so how can a simple kind of loose coupled messaging system could possibly do the trick instead and efficiently connect my systems?? Well today in state of the art architectures, inter-applications communication is (in most cases) handled through web services, at least for communication outside of the company, or between systems that need to be kept independents and probably implemented with different technologies or by different teams. So will REST become the new standard the same way web services did in the past years?
My understanding of REST is that it's mainly useful for CRUD like operations, even though you can add support for more custom verbs than the standard HTTP verbs (but then you lose part of the advantage of seamless and full integration on the web that you would have by using only standard web and http technology). The main purpose of REST is to see business entities as web resources and access them the same way you would access a web page or an image or any other resource through HTTP. Great thing about the idea is that there is nothing new except! If you know how to get an Http resource through its URL, you know how to get a customer entity through REST, isn't that great? It means that interconnecting applications could prove dramatically easy. However if you need a "real" business service that does more than just CRUD operations, then you better off, IMHO, keeping working with classical web services, WSDL and SOAP over HTTP (or other transport layer BTW). To summarize, my understanding is that for enterprise level, business applications, classical Web Services could still in many cases remain the best choice. Another scenario is the need for advanced enterprise wide services like security, confidentiality, transaction (even though transactions on the web has to be taking with care, we should rather be talking of compensation systems), asynchronous processing, then classical services will have much more to provide with the WS* implementations.
Another point to note with REST is that the communication is quite "relaxed". There is no notion of strong data type as there is with WSDL contracts. Therefore it's up to the client to know about the data that is received. If you need extra expressivity for your service then REST might not be the best choice. Well one can argue than REST can get business entities in an XML format, so you can add expressivity through schemas. Other issues I can foresee: how do you handle versioning of your services with REST? How do handle service location and service directories? Well there are many aspects to cover and would require more writing (and more investigation!) and will not be covered in this quick overview.
On the other side, for web facing services, REST will be a great solution: after all, most of the mashup web scenarios are using CRUD operations, and not even CRUD operation but simple read operations in many cases. REST is then much easier to use to mash up services than going through web services which need proxies to be accessed, and specific knowledge of SOAP and WSDL. And for what security is concerned, forget about all WS* specification: just use standard web security protocols, making interconnecting systems on the web in a secured way much easier and accessible to more people.
Well that was just my basic vision after first a first go through REST talks here and there, let's see in the future what comes up!
Oh, another wonder I had: hey! we're having this new, exciting feature of Microsoft.NET framework called WCF and it is all about connecting systems in a (as far as possible...) technology, protocol and transport independent way. So what about REST versus WCF?? Well good news is that WCF now allows to expose services through REST and consume REST services, so this is just a great thing, because one can invest on WCF without having to wonder if REST and a REST implementation would be a better choice: no worries: it's part of WCF through the new WebHttpBinding! So let's see how easy it is to build a WCF service, expose it through SOAP and with simple configuration change, expose it through REST. Haven't tried yet but should be pretty straightforward! We can see with this specific case an example of how powerful and extensible is WCF!
While we are talking about Microsoft and Microsoft technologies, I guess that REST will be interesting for Microsoft in many scenarios, let's see what they do and if they use REST for interconnecting their various systems. For instance we can already see coming the generalization of the use of the Entity Framework and especially the EDM (Entity Data Model) aspect for interconnecting Microsoft systems and exchanging data (more on another post). So REST would be a way to exchange the EDM entities across systems like Astoria Data services, Velocity, SharePoint and much more… And I was telling that REST seemed a good candidate for CRUD operations; well velocity and Astoria are all about exchanging data in a CRUD fashion, aren´t they? So let´s see how all will be consolidated in the future!
That´s it for this first overview of REST versus Web Services.
Comments