RESTful really just means Weblike

1. AFAICS this article does not sufficiently stress that REST is just the architectural style of the good old World Wide Web. The Web that we have grown to know and love, the Web that TBL invented and gave free gratis and for nothing to a (mostly ungrateful and largely uncaring) world. So the onus is on anyone who doesn't like REST to explain why it wouldn't work in any given application, when it certainly seems to have worked quite well for the Web itself.

2. "SOAP can be differentiated from REST this way; to use SOAP, developers have to understand the XML spec and will generally need a SOAP toolkit". That's quite true. But, to put it more simply, SOAP is to all practical purposes the exact opposite of REST. Whereas REST allows you to GET, POST, and PUT representations of resources that can be absolutely anything, SOAP extends the RPC model to the Web by defining interfaces for every separate little method. Both SOAP and REST have their uses, but for my money REST should be the default, with SOAP considered only if there is some special characteristic of the application that requires it.

Re: huh?

Think of it this way: Let's say you are looking to get healthy and want an appropriate diet. You have two friends which attempt to give you healthy advice. One of them tells you "try lowering your carb and fat intake, cut down on burgers, and eat lots of veggies". The other tells you "you should only eat things which are good for you."

Now, compare those two statements. One seems like a pretty specific recipe for a healthy diet; the other more like a generic contemplation of what a heatlhy diet should be.

This is pretty much the comparisson between REST and SOAP. SOAP is a web services communications protocol. It is complete with message format, interfaces, and command structures. REST, on the other hand, is--well--it is like a generic contemplation of what a client-server communication should be.

While SOAP tells you "If your message is writting in X format, and says 123, then server responds with ABC", REST tells you something like "if you send a message to the server, the server should respond appropriately." It's not even "apples vs. oranges", it's more like "apples vs. agriculture".

Of course, this is an oversimplification, but that's basically it. You hear lots of people argue over "REST vs. AJAX vs. SOAP" or some such, but this is nonesense. It's like arguing over the South Beach Diet vs. the Atkins Diet vs. eating healthy food: it means nothing; and worse, it implies a misunderstanding or misrepresentation on the part of the speaker.

The point is that REST does not imply any specific protocol nor communications standard, it merely means stateless communication between client and server, which is purely conceptual. When people advocate REST against, say, SOAP, what they really mean is "I don't like SOAP, so let's do something else--I don't know what, but let's", which is really not a bad thing to say since SOAP is pretty much bloated and overkill for many applications; but the hidden meaning is that there is no indication as to a substitute. This ends up meaning that everybody invents their own, and ends up sometimes being worse.

-dZ.

Sounds to me like....

.....a verbal representation paradigm for exsanguination incidents and their postulated relationships with previously established facts*.

*Stating the bleedin' obvious with lots of wankwords.

Re: Re: huh? ... By DZ-Jay Posted Tuesday 18th August 2009 11:01 GMT

dZ,

REST is also a Systemic Malicious Vulnerability in any Programming Regime because it allows for Obfuscation of Code Source to be used by Proxy Puppets/Expendable Assets and is therefore a Trojan Component/Element?

School's Out

I've got Restful Web Services (O'Reilly) and am still not clear. REST addresses a web page rather than carries a message to it. This can work for lots of things but where you need to carry a lot of state I'm not sure REST is practical.

The idea is however persuasive. However I could not work out the point of the article - the Cloud was only mentioned, not developed.

Beware RESTifarianism as a religion.

REST is an approach or paradigm that in implementation is nearly always linked with the HTTP protocol. You could actually take a REST approach with many other technologies even SOAP.

Both support a Document oriented approach to information exchange and SOAP also supports an RPC oriented approach.

If you want to do something basic then a HTTP/REST message would differ from the equivalent HTTP/SOAP message by 3 HTML elements. i.e. not by much.

If you want to do something complicated, e.g. message level security, reliable messaging, event based exchange, asynchronous messaging etc. then with SOAP you would select the appropriate public standard specification. With REST you would have to invent your own way to do it.

The assertion that the Internet is REST based and scales well because of this is faulty as most of the web pages we actually use are usually stateful using cookies and other technology , also you will find that only two of the REST verbs work reliably over most of the Internet. The challenge of making a web application scale is basically the same irrespective of technology, the more you can defer or remove the handling of state the better the application will scale. A REST based approach to automation of a very statefull process will still have scalability problems to solve.

REST is appropriate where the problem is simple, where QoS can be at 'best effort' and the number of consumers creating their own clients it high. It is better when use to manipulate documents than when used to perform controls

Personally when I have the option I choose to use SOAP as it comes with a toolkit of associated public standards that means I don't have to re-invent the wheel. However I'm working B2B and enterprise back office and need a lot of these capabilities. If I were working in Business to Consumer and Web Front end and wanted my services to be 'mashed up' by as many people as possible, I'd at the very least provide a REST option.