Web Services are by definition exposed services on a network that enable communication between one or more electronic devices, being able to send and process data according to their functionality.
This notification in turn, follows some protocols, mainly related to the format of data transmission, which allows, once a system implement these rules, any other system that follow the same protocol is able to communicate with it.
Because of this, Web services have become extremely popular because eventually allow communication between entirely different platforms (Java, C #, C ++, Ruby) without much effort.
Among these standardizations stipulated, the two most prominent are the SOAP and REST design model, which we will discuss the following topics.
The SOAP protocol, short for Simple Object Access Protocol, is a specification for exchanging information between systems, i.e., a data format specification for sending data structures from service, with a standard to allow interoperability between them.
Design assumes the use of XMLs to transfer objects between applications, and the use, as transport, of the HTTP network protocol.
XMLs specified by the SOAP follow a pattern set in the Protocol. This pattern is so that, from an object, you can serialize it to XML and also deserializes it back to the original format.
In the format of the objects, the protocol that are also defined standards that must follow the SOAP services, namely, the specification of the endpoint that theSOAPimplementations must have.
The object serialization, just described, aims to form a SOAP message, made up of the object named SOAP envelope, or SOAP-ENV.
Within this envelope are two more components: headerSOAP, which has request information of request metadata attributes, eg, IP source and authentication; and the SOAP body, which has information concerning the request, as the name of the methods you want to call and the serialized object that will be sent as payload of the request.
In Listing 1we see an example of a simplified SOAP envelope representing a SOAP request. In it we can clearly identify the body and header elements and also have a glimpse of the SOAP syntax. Inside the body is possible to see the method description for which this envelope should be directed (GetMagazine) and the specific payload that was sent to this role.
Listing 1. Example of a SOAP envelope carrying an object named MagazineName".
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header> </soap:Header> <soap:Body> <m:GetMagazine xmlns:m="http://www.example.org/revista"> <m:MagazineName>Web Services Magazine</m:MagazineName> </m:GetMagazine> </soap:Body> </soap:Envelope>
As seen, there is not much secret in transport objects via SOAP. In the case of our example, the request toGetMagazinemethod is sent to the server along with theMagazineNameobject, which will serve as the input parameter to ourmethod and has, as content, the String "Web Services Magazine". On reaching the server, this information is parsed and the application performs the logic required to process it.
As good practice, this service also has its operation and input data format specified by the SOAP protocol. This definition of the methods that comprise a web service SOAP must function is made by an XML document called WSDL, short for Web Service Description Language, XML that describes the data format you accept the service, and its operation behavior (if is asynchronous or not, for example) and the output data of the method, including the format from the SOAP envelope to be returned.
Listing 2 shows a WSDL example specifying ourGetMagazineservice, which accepts a String as input and returns, in return,another String.
Listing 2. Sample WSDL forGetMagazineservice.
<definitions name="HelloService" targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <message name="GetMagazineRequest"> <part name="MagazineName" type="xsd:string"/> </message> <message name="GetMagazineResponse"> <part name="MagazineName" type="xsd:string"/> </message> <portType name="Magazine_PortType"> <operation name="GetMagazine"> <input message="tns:GetMagazineRequest "/> <output message="tns:GetMagazineResponse "/> </operation> </portType> <binding name="Magazine_Binding" type="tns:Magazine_PortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetMagazine"> <soap:operation soapAction="GetMagazine"/> <input> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="encoded"/> </input> <output> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="encoded"/> </output> </operation> </binding> <service name="GetMagazine"> <documentation>WSDL File for HelloService</documentation> <port binding="tns:Magazine_Binding" name="Magazine_Port"> <soap:address location="http://www.examplo.com/Magazine/"> </port> </service> </definitions>
As we can see, the WSDL has several attributes for the service, as the location of endpoint, names of each of the services, names of each parameter and its respective type.
By this definition, any external system can communicate with the web service we created in the WSDL, sending the request through the SOAP protocol.
Among the WSDL elements that presented in Listing 2 shows that the definition of a service is basically composed of four main parts.
The first of them defined by tag <message> is defined where the format of our data, these can be input and output. At this point, we can use both primitive attributes, as for example the use of string, as well as schemas using XMLs (called XSDs) to define our objects.
Having defined the format of our information, the second part of a WSDL is to specify the operations that we want to expose and their inputs and outputs. This is done in the tag <portType>, where we define the GetRevista operation and determine also the input and output data, based on the tags <message> we created earlier.
Then we specify the WSDL tag called <binding>, and within this, our portType tag (created in the previous step) and their respective operations to a service. This service, which represent the implementation of our web service, is given the tag <service>, which made explicit the address of the endpoint through the <soap: address location>.
On top of this, the SOAP also provides some interesting features, such as WS-Addressing.
This technology allows, since some information sent within a SOAP envelope, it is possible to send an extra parameter defining a callback endpoint to be called once the request has finished being processed.
Thus, once you finish the request, the web service can call this callback URL, passing in its contents the result of processing and allowing thus the asynchronous work between systems.
REST architectural model
By introducing and adopting these standardizations, many systems have begun to implement this model in creating your web services, making the SOAP protocol to become one of the key technologies in the development of web services in enterprise systems.
However, the SOAP protocol also brought several disadvantages. The first (and perhaps the most important) is the fact that the carry all information within a SOAP envelope XML, the contents of data sent from one system to another becomes many times larger than required, increasing both consumption of network bandwidth as the data processing time.
Second, the use of web services SOAP does not make the correct use of HTTP verbs. This is due to the fact that all SOAP requests are made through the POST an XML containing the SOAP envelope.
However, in most requests, the most appropriate would be another word, such as a GET or PUT, according to the functionality exposed by the service. Because of this limitation of the protocol, SOAP eventually counteract some of the principles of good HTTP modeling, hurting the good practices of this specification.
For these and other reasons, developers and researchers have adopted another approach to create your Web services, called REST services.
The modeling behind a REST service assumes follow the good practices of creating HTTP services and use these patterns to develop simple and performers web services.
One of the crucial points in this architectural model is the correct use of the methods provided by HTTP. Unlike SOAP, which only uses the POST method to transmit data, a REST architecture provides that, in an ideal scenario, the HTTP method to be used is directly related to the functionality of the service to be consumed.
Therefore, search for information services are made through GET methods, update information services through PUT methods, data service creation through the POST method, deletion services through DELETE and so on. From the correct use of HTTP verbs also gain the advantage of not having multiple URLs for each of our services and can only expose a URL and, as the method to perform a different action.
As an example, let's imagine a simple CRUD service (creation, updating, data retrieval and deletion) to customers. Within a REST architecture, this service can be set only with a URL, for example: http://nosso.exemplo.com/client/12345. To make an inquiry to the customer 12345, just conduct a GET request to the URL mentioned and to delete it, perform a DELETE request.
The same can apply to PUT and POST requests, which used the body of the request that was sent to us to upgrade or create a new entity in our system, respectively.
Thus, it is easy to see that using the methods correctly, web services REST become very simple and highly intuitive be developed without the need descriptions such as extensive documentation or WSDLs to explain its functionality.
Another advantage of the REST in relation to the SOAP refers to the data format to be trafficked.
While SOAP is restricted to use XMLs, REST does not impose restrictions on it, that is, anyone can be sent in their requests.
Directly related to this, as good practice, a REST request must always contain the header Content / Type to explain the data format in your application and for return, the Accepts header, determining the data format that the application expects.
As an example, if an application wants to send a given XML and receive, in return, a JSON, it just explain both formats in their headers and the REST web service must be able to resolve the request in accordance with those needs.
Within the REST, another difference is called HATEOAS, short for the Hypermedia the Engine of Application Status. Considered one of the main benefits of this architecture, the HATEOAS states that, within a REST application, the state of application and user interaction should be controlled through URLs (Hypermedia) returned by the service. This implies that in a REST service when the first URL that application is accessed, all possible "paths" that the customer can follow from there is returned in the request's response, as the URLs of the services that can be invoked in next step.
Through this technique we avoid many problems for our customers, since they need only have the first URL of our application hardcoded into your code, enabling the following URLs to be captured during the actual execution of the web service.
Anyway, both technologies have their advantages and disadvantages and have specific situations in which fit best to solve a particular problem. So to choose the right technology for your project, the opinion of experienced professionals and an analysis of the entire execution context in which services will run is advisable.