Why REST is called lighter weight Web Service?

[ankur rathi]

Why REST is called lighter weight Web Service??? (It's mentioned in JR FAQs as well)

I think REST is just a way of thinking how web works. Each resource accessed by client put it into a new state. All resources are linked like state machine. The output sent to client is actually representation of resource.

And web service is a technology, where output of a service is sent in the form of XML (only) to caller.



Thanks.

[Scott Johnson]

Why REST is called lighter weight Web Service???

One reason is because there is a certain amount of overhead involved in creating, transmitting and parsing the XML for a SOAP envelope.

[ankur rathi]

Originally posted by Scott Johnson:


One reason is because there is a certain amount of overhead involved in creating, transmitting and parsing the XML for a SOAP envelope.

That�s okay but REST doesn't say that resource (or representation of resource or document - please help me with exact word) sent to the client should be in the form of XML only.

[William Brogden]

The overhead on the client side in creating a SOAP request and sending it is really quite annoying. Creating a simple URL, creating a HttpURLConnection and doing a GET or POST is so very much simpler.

On the server side parsing a SOAP request is time consuming also.

REST is also lightweight because it discards all the SOAP baggage of WS-* headers, signing, encryption, etc etc. Naturally this means REST is best suited for simple tasks that dont require these added capabilities.

Bill

[Peer Reynders]

Edit:

"REST doesn't say that the representation sent to the client has to be in XML".

And that is exactly the point. With SOAP you have to pry (parse) the payload out of the SOAP body, you have to parse the SOAP headers to support the various WS-* standards. SOAP dictates that the payload is XML (SOAP with Attachments (SwA) being the exception because it is a MIME envelope that carries the SOAP envelope and the attachments). SOAP was designed to be extensible and it was designed to function in a variety of transport environments. Yet HTTP is being used in 99% of the cases as the transport for SOAP (at least for one hop) which limits the SOAP functionality that you can use. SOAP was designed to travel over multiple intermediary SOAP nodes between the initial sender and ultimate receiver - yet in 95% percent of the cases the SOAP envelope simply travels between an HTTP client and HTTP server or back. SOAP was also originally (back when it was still called the "Simple Object Access Protocol") designed to beam objects over the wire - then that turned out to be a bad idea (Spring Framework: Why Contract First explains why) and now the "document/literal" mode of messaging is a best practice. The document in "Document/literal" is basically a representation. An endpoint in "document/literal" mode doesn't support operations (the WSDL still provides them as access points for the code generators - but they don't appear in the SOAP body) it simply accepts different types of documents (different types of representations). However the definition of the endpoint still revolves around one single URI - which still gives it an RPC flavor.

Tim Ewald: "It's depressing to think that SOAP started just about 10 years ago and that now that everything is said and done, we built RPC again"

So SOAP involves a lot complexity for extensions that are never used by the majority of setups - yet they still have to pay the price for that complexity. Furthermore SOAP tries to abstract away the nature of the transport. But that abstraction leaks because there are things that HTTP doesn't support - like the Notification and Solicit/Response Message Exchange Patterns, so then you have to use SOAP extensions to fake capabilities that are supposed to be inherent to SOAP. By abstracting away the transport you are also abandoning the inherent features of the transport - e.g. SOAP web services do not use cookies.

REST is considered light-weight because it disposes of all that essential and accidental complexity of SOAP. REST treats the web as the resource-oriented architecture it was designed to be in the first place. It's not RPC, not object-oriented - it's resource-oriented.

[ankur rathi]

I am still confused.

Do you all mean that, because REST can transfer XML without all overhead that SOAP has, and so it's called lighter weight web service???

But my confusion is why do we need REST for transferring XML??? Can't we transfer XML just as we do other data, like this:

https://coderanch.com/t/224584/Web-Services/java/xml-over-http

And moreover I still think that REST is not any mechanism to transfer data. It just a way to see it...

Thanks!

[William Brogden]

But my confusion is why do we need REST for transferring XML???

You don't need REST - it just turns out that thinking about transfer of resources - XML or whatever - can be simpler with REST style.

Certainly REST is not a mechanism to transfer data! HTTP provides the method, REST provides the conceptual framework "to see it."

Bill

[Cameron Wallace McKenzie]

Bill and Peer.

Just wanted to say that I've very much enjoyed this thread. Very insightful.

-Cameron McKenzie

[Peer Reynders]

"REpresentrational State Transfer" (REST) is the name that Roy Fielding gave to the way the web naturally operates (the way it was designed to operate). Systems designed to follow the same style are considered RESTful. Many XML over HTTP systems are simply customized or degenerate versions of XML-RPC. And the emphasis is on RPC.

RPC style messaging was really popular in the early days of SOAP (still is really...), most likely because it is a way of thinking that most programmers are used to. However remote RPC has some issues and encouraging tight coupling is one of them. Web services are supposed to be loosely coupled! To encourage loose coupling document style SOAP endpoints are now considered a best practice. However even document/literal SOAP endpoints retain some aspects of RPC-ness - you throw different (data-)types of requests towards the endpoint (URL) and you get information of the appropriate response (data-)types back.

That is not how the web naturally operates. One URL usually represents one resource (page), which has one representation (though there may be multiple versions - one for each supported media-type) and that representation may contain links (hyperlinks) to other resources - that is the nature of the web - it is resource-oriented.

So RPC (the way programmers prefer to communicate over the web) and resource-orientation (the way the web was designed to operate) are different. This kind of difference is often referred to a an "impedance mismatch". Trying to work with objects when the data is stored in a relational database leads to the problem of the "object-relational impedance mismatch"; trying to store objects in XML leads to the problem of the "object-hierarchical impedance mismatch". Whenever you try to address such an impedance mismatch a lot of additional complexity results from trying to overcome it. It usually requires additional abstractions, levels and layers. The mapping is usually incomplete and only a sub-set of features are supported on both sides so that the strengths of either side are weakened or lost. And ultimately most abstractions leak so concepts from one side appear on the other further undermining the "purity" of each paradigm as you are unable to hide the "other side". In some cases the cost of additional complexity is worth it. Relational databases are great for dealing huge amounts of data and object-orientation often helps to manage the complexity of processing. In other cases the cost for overcoming the "impedance mismatch" isn't worth it - it is simply more effective to work with the paradigm of the original environment rather than trying to force your preferred paradigm on top of it at the risk of severely compromising the capabilities of either of them.

This is why REST proponents want everybody to treat everything on the web as a resource-oriented architecture (with its linked resources) - because that is what the web was designed to be. Treating it as anything else diminishes its power and leads to extraneous complexity. Object-orientation has taught us that we need to control essential complexity and eliminate accidental complexity. As far as REST proponents are concerned only accidental complexity can result from any attempt to turn the web into "something else".

A �bad� example: The Flickr API claims to be RESTful but isn't - the URI contains scoping AND method information, so it is considered a REST-RPC Hybrid. What is worse, it uses an HTTP GET to modify the data set! HTTP GET and HEAD requests are supposed to be safe! Also any non-idempotent use of HTTP GET, HEAD, PUT, and DELETE violate REST principles (and the rules of the web).