1 - Overview
In this document we will talk about two of the systems to work with Web Services that nowadays are fighting for domain the market in this area, which is one of the most important in the computing.
SOAP (Simple Object Access Protocol) is a protocol which defines how two objects in different processes can communicate data between them. This data is formatted in XML (eXtensible Markup Languaje) which is (as its own name indicates) a markup language derived from SGML (Standard Generalized Markup Language). It was developed by W3C (World Wide Web Consortium) looking for simplicity, generality and usability over the Internet. For the transmission of this XML messages usually relies on HTTP (HyperText Transfer Protocol). SOAP is under the control of W3C.
The typical aspect of a SOAP message is like you can see in the next image, the entire document is written in XML and it consists in a SOAPEnvelope which contains the optional SOAPHeader and the mandatory SOAPBody. The SOAPHeader allow us to provide extended information about the message like authentication, transaction management and payments. Inside the SOAPBody, on each body entry is where the data specific to the actual method of the Web Service request call is stored, such as method name and parameters and/or return values for the method invocation. The structure of the data inside the SOAPBody is organized according to the representation given by the WSDL file in the part where defines the message. The SOAPFault is used to inform about error or status.
 |
| Example of SOAP/XML |
This idea is take advantage of what is already there, this means take advantage of the web itself. For REST there are only resources which are identified by only one and unique URL (or URI Uniform Resource Identifier), these resources can have many representations and the client can ask for each representation of the resource depending of the way he needs those resources.
One of those representations can be JSON, an acronym of JavaScript Object Notation, created by Douglas Crockford is a light format to interchange data. The simplicity of JSON has made it really used, as an alternative to XML in AJAX and in many others spaces like Web Services.
In the next image we can see the use of the REST architecture using HTTP for the interaction between client and server in a system for weather information. Besides we are using JSON as the representation for the resource. In this case we want to know the temperature in Paris in ºC, so we send the request to the weather resource which gives the representation according to our petition. Note the structure of the URI for this resource using only slash and names without any type of typical parameters like weather?city=Paris&units=C, which is not a clean URL and it is not according to the REST style. The information of parameters is stored inside the HTTP request (and response) and the MIME - types are used to inform of what representation are we using for the information.
 |
| Example of REST/JSON |
2.1. Proxy Servers (Web intermediaries)
For REST there can be intermediaries between clients and resources to support different kinds of elements like performance or security. In SOAP it is almost necessary define a proxy which help us to hide the construction and parsing details of the web service within this proxy. This way we don’t have to manually construct the message which it will be sent to the Web Service, or parse it when we receive it, saving time coding and possible errors, all this behavior will be encapsulated in the proxy class.
2.2. Transitioning state in a client application
Respect of the states of a client application, REST is designed to be exactly a way for the user (the browser) to progress between different states depending of what the user choose to be his representation of the resource he wants to see. This progression through states is usually done by the selection of links by the user. In SOAP there is no this type of transitions, mainly because it is not an architectural style, its only concerning is the transfer of information between the client and the server and the way this has to be done.
2.3. Caching (i.e., performance)
In REST all the responses has to be capable of being labeled as cacheable or non-cacheable, this helps to improve network efficiency avoiding to reload a resource which has been already requested. Also the information transmitted is less than in SOAP, in SOAP even with only one element to transmit it has to be created a complex WSDL file and also the SOAP message which generates an overload if you only need to transmit simple elements. This is one of the reasons to use REST instead of SOAP if you only need to transmit small quantity of information.
2.4. Web evolution (semantic Web)
In terms of the famous semantic Web, REST has advantage in some way because it uses the web as it should be used, this means using what is already created and not creating new things to support operations that they are already there. We can talk here about the verbs of the HTTP protocol like GET, POST, PUT, DELETE, etc. A lot of applications and systems base their work only in the use of the GET verb, and the adding of parameters to the URL (violating the principle of “any resource is referenced by only one URL”) which makes more complicated understand where you are and what is doing the webpage you are visiting. But if you use these verbs in the correct way, and take advantage of things like the MIME - type to know what you are transmitting, and take care of use “clean urls” the web will be as it was meant to be, and it helps to make the utopic (at least for me) idea of semantic web more close to these days. And all of this will make the web for the user much more transparent, which at the end is the objective of any programmer, make the user believes that you are not there.
2.5. Generic interface (versus custom interface)
The interface which REST use can’t be more generic, it is based in the verbs of HTTP GET, POST, PUT, DELETE, HEAD, etc. which any browser is capable of manage. For SOAP is based in the use of WSDL files which tell us how we have to interact with the Web Service in terms of how to build the proxy, SOAP message and where we have to send this message helping us of the proxy.
2.6. Interoperability
With SOAP you have complete interoperability always you have access to the WSDL file and a system which was able to process XML files. Also it is a highly used standard which a lot of companies use in their software development so the probabilities to find some company which uses it and have information about the Web Service which implements are very high. For REST is not so sure because is not so standardized which makes that you could find a Web Service and you didn’t know how to use it, which is a huge problem because if you don’t know that, it means that you can’t use that Web Service correctly from the beginning and you will have to spend time figuring out the way that it works to do a correct use of it, time that you can spend working in your own work.
2.7. Processing the payload
The processing of the payload in SOAP / XML is heavier than in REST / JSON, because what it is processed is at the end a document XML, and is more difficult to process than a document written in JSON, so in these terms of processing the union between REST and JSON wins. Besides the information transmitted in SOAP has more elements which are not information themselves, only are information of control to can process the SOAP message, I am talking about the elements I mentioned in the introduction of this document like SOAPEnvelope, SOAPHeader, SOAPBody, etc.
2.8. Recommendations
The main recommendation would be that use the technology which would be better for the system you are developing, you have to know when choose SOAP / XML and when choose REST / JSON. If you need to transfer a really big amount of data and need this data completely structured and organized and also need tools and elements to have controlled all the time the application and not only when this was finished, also when you were testing and during the development process, you should go for SOAP. But if you don’t need so much background and your application is simpler without the need of that completely control you should go for REST.
2.9. Who uses what in the real-world
SOAP is more generalized since it has been in the market as a technology more time than REST, that does not mean that it was created a long time before REST, because the origins of REST as I said in the introduction are in the doctoral dissertation of Roy Fielding in 2000, and XML-RPC which is based SOAP is from 1998, but REST has not been used as it has been used nowadays until few years ago, so SOAP has more advantage than REST in this aspect. Anyway the simplicity of REST is doing each day that more developers and enterprises choose it as the way to create their software, relying in its transparency instead the “complicated” and overloaded SOAP way.
3 - Opinion
After work with both technologies I have to say that do this work with the SOAP / XML way was easier, it is not exactly because SOAP or XML were easier technologies, it is because the tools to work with them are really more advanced and it was so easy as create a java class which managed the logic of the Web Service and edit the client version to get something more user friendly than the default client generated by Eclipse (in this case the IDE that I used).
To find the way to get working with the REST / JSON application was a really more complicated work. Before know about the tutorial of REST in Moodle I started to work with a java library called RESTlet, which offers APIs for different technologies (Android, JEE, JSE, GAE, GWT, etc.), but it was really difficult find examples of its use and particularly examples based on the use of JSON as interchange format, so I decided to look for other way and after read about the tutorial in Moodle I started to used Jersey, a library for JAVA which is an implementation of JAX-RS (The Java API for RESTful Web Services). It uses annotations to define the REST elements in the Java classes. Also the JAX-RS specification supports the creation of XML and JSON using the Java Architecture for XML Binding (JAXB).
So it has almost all I needed, but even with that, understand the way REST works was hard because I am not used to use the kind of things REST is based, the use of the “clean urls” without explicit parameters using the interrogation symbol, or the concept of resource and representations of that resource, so I had to read and investigate a lot to understand the concept before start to do any code in order to avoid do useless work and even with that I lost some time trying to do some applications examples with RESTlest and Jersey, but I think it was not a completely waste of time because it helps me to get experience with the REST style.
But leaving my personal experience with both technologies behind I have to say that REST is really interesting and really simple, and comparing the amount of information transmitted and the work that Eclipse automatically does in SOAP, I am not so sure that it was easier work with SOAP if you don’t have tools to create the WSDL file or the classes to contact with the Web Service, off course you can learn to do that,, and do it perfectly, without any errors (what is difficult), but even knowing how to do it, how to build those classes, it’s a time that you can use for do other things more important and not mechanical code, that’s why is so important have the correct tools to work with SOAP, to avoid the wasting of time which is create all that extra code, a workload that could be done for a machine automatically.
4 - Conclusion
To summarize it happens something similar to the fight XML - JSON, SOAP has behind it a lot of more support that REST, more tools and more standardized systems to work with it, but despite all of that, the simplicity of REST makes it a really important alternative when you don’t need all the background things you have to define to put to work a Web Service based on SOAP.
So if you need simplicity use REST but that same simplicity will make that at least for now, tasks like testing will be harder than in SOAP, which is a technology much more standardized and expanded and that has more support and tools to work with it.
Finally the next years the Web Services and all the things in relation with the Web itself like the Cloud Computing are going to keep rising and they are going to be one of the more important sectors in the computing world because for the user is easier and for the enterprises are cheaper. So in a near future we will see probably the increment of this type of technologies in decrement of the traditional ways to build software (in fact it is actually happening).
5 - Bibliography
- http://en.wikipedia.org/wiki/Representational_State_Transfer
- http://es.wikipedia.org/wiki/Simple_Object_Access_Protocol
- http://blog.movilforum.com/apis-seguimos-con-el-rest-vs-soap/
- http://www.slideshare.net/kaniskamandal/rest-with-json-vs-soap-with-xml
- http://stackoverflow.com/questions/8599833/how-soap-and-rest-work-with-xml-json-response
- http://blog.feedly.com/2009/03/03/jsonrest-vs-xmlsoap/
- https://devcentral.f5.com/blogs/us/soap-vs-rest-the-war-between-simplicity-and-standards
- http://itenterprisearchitect.blogspot.ie/2010/09/rest-vs-soap-web-service.html
- http://www.skill-guru.com/blog/2010/11/02/goodbye-soap-welcome-json-rest/
- REST with Java (JAX-RS) using Jersey - Tutorial
Un saludo!
No hay comentarios:
Publicar un comentario
Ponte un nombre aunque sea falso, que Anó-nimo queda mu feo :(