Advertisment

SOAP and the REST

author-image
PCQ Bureau
New Update

Though the term REST (Representational State Transfer) itself might be new for many, but using, and even writing applications for it, is definitely not. WWW (World Wide Web) is based on this architecture. REST is an architectural style that uses other standards, like HTTP, URL, XML, HTML, GIF and JPEG. 

Advertisment

There has been some buzz about another technology called SOAP (Simple Object Access Protocol) that might ultimately replace REST (see Introducing SOAP, page 70, PCQuest, April 2001). For starters, SOAP does not propose any new architecture, while REST is an architecture style. Instead, it defines a standard for all communication between clients and servers across the network, irrespective of system types and transactions involved. It does not propose any architectural changes in the way Web goes around its business today. In fact, it can operate well over the REST-run Web as it is today.

The REST way of Implementing the Web Services

How they differ



To understand the difference between how REST and SOAP work, consider an online bookstore. A common transaction would be a user wanting to see a list of all the books by a particular author. Using traditional REST, a client would have to provide the website with the corresponding URL. The client then sends an HTTP GET request for that particular URL and the website responds with the corresponding HTML/XML file containing the list to the client. So, with REST the Web service is fully aware of the exact resource being accessed, for example, www.bookstore.com/ authors/puzo or

www.bookstore. com/authors?id =segal, etc. All Web pages have unique URLs and the Web service can identify the exact resource the client needs, by looking at the URL.

Advertisment

Contrast this with the way SOAP does things. The client no longer exposes the exact URL of the resource it’s requesting.

Implementing the Web Services using SOAP
Note the use of the same URL (URL 1) for all transactions. The SOAP Server parses the SOAP message to determine which method to invoke. All SOAP messages are sent using an HTTP POST

Instead, it now creates a SOAP document and the information regarding the document being desired is stored inside this SOAP envelope. This envelope does expose a URL though that of the SOAP service, which can ‘peek’ inside the SOAP envelope and, thus, know which resource is being referred. So, the client now sends this SOAP document as an HTTP POST request to the URL exposed. The Web service at the server-end now needs the help of a SOAP server, which identifies the resource desired by the client by looking inside the SOAP envelope and invoking the procedure indicated within. It responds with the results of that procedure call wrapped inside another SOAP envelope. The Web server forwards this response to the client where it is unwrapped by the client and the resulting data (in our case, the list of books by the author) obtained. For example, the SOAP equivalent of accessing something like www.bookstore.com/authors/ puzo would involve the client sending a request along these lines:

Advertisment















Puzo








The Web service would HTTP POST this to the SOAP server indicated, which would be something like www.bookstore.com/soap/ servlet/messagerouter. Now, this URL can be the same for all requests. Of course, you’ll have to program the SOAP service at this URL to be able to interpret all kinds of requests that you expect it to cater to. So, potentially you can run your entire site with just a single exposed URL–that of your SOAP handler. In the above example, the SOAP handler identifies that the procedure being called is ‘getAuthorBooks’ with the tags inside it indicating the parameters with which this procedure is to be called, ie, ‘author-id = Puzo’. You would need to implement the functionality corresponding to the getAuthorBooks procedure (not shown here), which would, typically, look up your books database and return books by a particular author. The resulting SOAP response would look something like below.













The Godfather


Fools Die


















This message is then interpreted at the client side by a SOAP aware component (the one which created the initial SOAP envelope in the first place) and the result (the book list).

“I can’t determine if the message is allowed since I don’t know what Resource it is targeting

Advantage SOAP 



The advantage of convenience gained by exposing only a single URL is compensated by the fact that while using SOAP, proxies and other such ‘intermediaries’ like gateways are rendered useless. Proxies are designed to block and/or allow access to resources desired by the client by looking at the URL of the request. Now, since the information about the exact resource being accessed is hidden inside the SOAP envelope, and a common URL exposed, a proxy (which cannot peek inside the envelope) has no way of identifying, and thus blocking, access to resources. You can, of course, block the URL of the SOAP server itself, but that would block access to all resources being accessed by that server and not just specific ones.

Another problem with SOAP is that each and every resource no longer has a distinct URL of its own as desired by REST architecture. Also, since ALL SOAP messages have to be sent as HTTP POST requests their results can no longer be cached. This is because HTTP POST, the way it was designed to be, represents content that is dynamic and hence cannot be cached. Also, SOAP, being a standard, is very rigid in how things should be. This is in contrast with the flexibility and scalability which REST gas to offer.

But then, even REST has a few problems. Sending confidential data as parameters in the URLs doesn’t please anybody. Also the advantage of each resource having its own URL can be a major headache (imagine a store with a million books) using a common URL, like SOAP does, would definitely be a better solution in this case.

REST or SOAP?



So, what do you use, REST or SOAP? Well, who says you can’t combine the two! While REST remains the preferred and the most cost-effective way for reasons discussed above, and is thus sufficient for most needs, it can be built upon to incorporate SOAP into it. Many experts call it RESTfulSOAP wherein you start in with the flexibility and convenience of the REST model and apply SOAP constraints on an as-per-your-need basis. Ultimately, it all boils down to getting things done the way you want to.

Kunal Dua


Advertisment