A Retrospective Look At Web Services

A Retrospective Look At Web Services

After a considerable break from reading about the web services technology, I once again visited the subject with a view to look at it retrospectively.

1.1 SOAP Web Services

SOAP Web Services is the original style of web services. It started with a specification about the web service: the WSDL file. This file had the same function as an IDL file had in the days of COM. And not surprisingly, because the SOAP web services have evolved from component technologies like COM and CORBA. So, the WSDL file defines the contract between the client of the web service and the web service itself.

In order to make the web service independent of the programming languages and their types, and also of the network transport, the WSDL became a detailed specification based on XML Schema that defined the data types, the operations and their parameters and the bindings.

The advantage of the detailed specification of the contract was that it allowed the client and even the web service to be written independently. That is, given the WSDL, a developer could write the web service to adhere to the WSDL spec and another developer could write the client to such a web service.

1.2 A C++ Example

Eventually what happened was that Soap Toolkits became available that could read a WSDL specification and generate the client side and server side code. For example, I had once a need to invoke a SOAP web service from a C++ program and there wasn't any standard IDE option to do this automagically. Therefore, I looked for and found a SOAP toolkit library called gsoap that would generate C++ code when it was supplied with a WSDL file.

For the client side, the gsoap library generates a set of files that contain the methods on the web service. These methods act like proxies to the client program. Internally, the generated code converts the parameters to the method calls to the appropriate request xml and make the call over the network to the web service. Consequently, from my source code, I could make the call to the web method in the generated code and the actual call to the web service would be made under the covers, so to speak.

For the web service side too, the gsoap library would generate a set of files that contain the methods of the web service. This code needs to be invoked by a transport handler like IIS or Apache web server. Once the call is passed on to the generated code, it converts the request xml into parameters and invokes a method in your code.

1.3 Microsoft .NET and Java

With MS .NET, it became trivial to write SOAP web services since the IDE took care of practically everything. All you needed to do was to select a Web Service project and annotate the web method with [WebMethod] and the IDE did everything else.

What was happening behind the scenes is that the IDE generated the WSDL for the web service and it generated the code to translate the request xml into parameters (much like in the C++ case) and at run time, it would make the appropriate call to the web method. And the response xml would be generated similarly.

On the Java side, there were frameworks like Axis from Apache that did much the same thing for java programs that MS .NET did for C# programs.

1.4 XML Requests and Responses

With the SOAP specification, there was a great amount of detail involved in generating the xml for the request and response for a web service method. There were four possible variations:
RPC / encoded
RPC / literal
Document / encoded (never used)
Document / literal

What these variations mean is that the xml generated for the request and response is different. The choice of which xml variation is used is what the WSDL specifies. In general, it doesn't matter much which variation is used. From the programmer's point of view, it doesn't matter at all because the SOAP toolkit deals with the details. From the point of view of performance or other such consideration also, the difference isn't great. After all, it is a few more or less characters to be transmitted. 

A toolkit like SoapUI will generate the correct request xml structure for any given WSDL taking care of the xml variation specified.

2. REST Web Services

On looking at all the infrastructure required to create SOAP web services, it became clear that a lot of it was quite unnecessary. What SOAP web services were providing is the ability for the programmer to write web services and their clients in terms of native data types. The infrastructure took care of converting the data from raw xml on the wire to native data types.

However, there was no good reason for this. Programmers had good libraries at hand to read the data in the xml themselves. So, what emerged is the practice of clients building the request xml in the code and parsing the response xml using DOM or SAX parsers. And likewise on the web service side.

In order to bring some kind of uniformity to this practice, a few standard mechanisms were proposed for the requests in terms of the common database operations:
C - create: http POST request
R - read and list: http GET request
U - update: http PUT request
D - delete: http DELETE request

This standardized use of the different HTTP verbs for different operations is referred to as the REST protocol for web services.

Basically, what was changed was two things: (1) the practice of xml being created and interpreted in the code of the web method itself instead of relying on an infrastructure to convert xml to native data types, (2) the call to the web method being made from the client directly using a library that allows making a TCP/IP call instead of letting the infrastructure do it behind the scenes.

3. Conclusion

What a lot of web service implementations do today is to use the practice of REST web services without the use of the REST convention. For example, they may use only the POST method for all the operations supported by the web service. We refer to such web services as REST-style web services.

The shift from SOAP to REST style web services has simplified the development process by removing all the "under the hood" kind of processing and making xml exchange explicit between the client and the web service.