huh?
Reading that made me feel stupid. I can understand the individual words, but the sentences they form mean nothing to me! All I've learned is that REST is a bit like SOAP, but not really.
The term REST keeps on popping up when vendors and analysts talk about cloud storage. We're told that RESTful interfaces are more advanced than traditional filer interfaces such as NFS or CIFS. What is REST all about? Let's take a fairly simplistic look at REST, cast an eye in the direction of its advantages over the traditional …
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.
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.
Good to see I'm not the only one who thought there was naught but a lot of words that don't really say anything in this article. And what does it have to do with storage...? Nothing.
The comment from amanfromMars carries almost as much meaning as this article :) Maybe Chris Mellor is really aManFromMars Mark 2?
I've been writing REST stuff since I was writing device drivers, a quarter century ago.
Oh, they were also multithreaded, reentrant, asynchronous (in some cases, isochronous), and expressed a "pseudo-OOP" model. In fact, the REST was a major part of the "pseudo-OOP."
Sheesh. Kids these days think they invented everything. They just have tools that abstract them from the bare metal.
Okay, that story was confusing as hell, but I think I get this stuff cause I am working with it right now, so here is my attempt at clarification:
1. The article is talking about REST from a file-transfer perspective. The idea is, that you could use NFS, CIFS, FTP, or whatever to copy a file up to a server. REST in this case is just another word for WebDAV. You can get a file from a server with HTTP/GET. You can upload with HTTP/POST, or delete with HTTP/DELETE.
2. The paper goes beyond "file-transfer" and is also talking about data-transfer. i.e. most people use SOAP in their web applications. But SOAP is conceptually based around actions. If you wanted to have your webservice deal with "users", you would have a bunch of methods like CreateUser, ChangeUserName, ChangeUserEmail, etc.
2.1 REST is not "method" or "verb" based. If you want to make the REST equivalent to the ChangeUserName method above, you'd simply GET the User object, update the name on the client, then POST the user back.
2.2 The REST server could then execute some business rules to see which field has been changed, check if the user doing the changing is allowed to change it, then optionally throw an error or save it to the DB.
There, that clears things up right? :-S
Sounds like the same old promises, repeated over and over: "REST is good. REST will free you from all your (scaling|integration|caching|business logic) worries. Come join us, and become enlightened by REST. (Two drink minimum; mileage may vary; some restrictions apply; see dealer for details.)"
Now, REST is fine and all (or at least no worse than any other protocol I've had to use), but at the end of the day it's one *very* small piece in the software solving the business problems I deal with.
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.
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.
Excelent summary. I agree with you entirely. The power I see from REST is as you say, the methodolgy, not necessarily the protocol. Of course I'd say that, I've been using a REST-like approach to SOAP for years:
1. Use sprocs (or whatever) to define a graph of objects
2. Return that object graph to the client via SOAP
3. Manipulate as need be
4. Persist back
At that point the webservices sanitize the data, check what was changed for security, concurrency, etc, then persist it back to the database in the proper order. Presto, I can code generate a web service with a half dozen methods while my peers are coding a method at a time for every conceivable action.
That being said, SOAP doesn't work well for large binaries, images etc. On my current project that is where "REST" really comes into its own. An ashx handler or two for retrieving and persisting images to a database works wonders.
Its all about using the right tool for the job, and telling evangelist types to go fuck themselves.