Why do we need RESTful Web Services?
I'm going to learn RESTful web services (it's better to say that I'll have to do this because it's a part of CS master degree program).
I've read some info in Wikipedia and I've also read an article about REST at Sun Developer Network and I see that it's not easy technology, there are special frameworks for building RESTful apps, and it's often being compared to SOAP web services and programmer should understand when to use SOAP and when REST could be nice approach.
I remember that several years ago SOAP was very popular (fashionable?) and item 'SOAP' had to be present in every good CV. But in practice it was used very rarely and for achieving very simple purposes.
It seems to me that REST is another 'last word of fashion' (or I can be totally wrong because I haven't ever seen REST in practice).
Can you give me some examples were REST should be used and why we can't do the same without REST (or why we should spend much more time to do the same without REST)?
UPD : Unfortunatelly I can't see any concrete arguments which can blow my mind in first comments. Make me think that REST is awesome technology!
I'd like to see answers like this:
I was developing another complex HelloWorld application and we need to transfer lots of / tiny data and I proposed REST solution to my workmate:
– Oh, damn! Jonny, we should certainly use REST for implementing this app!
– Yes, Billy, we can use REST, but we would better use SOAP. Trust me 'cause I know something about developing HelloWorld applications.
– But SOAP is old-fashioned technology from the last century and we can use better one.
– Billy, are you ready to spent 3 days for experimenting with REST? We can do this with SOAP in 2 hours..
– Yes, I'm sure that we'll spent even more time to achieve the same security/performance/ /scalability/whatever else with SOAP. I'm sure that HelloWorld applications should be developed only with REST from now.
REST should be used if it is very important for you to minimize the coupling between client and server components in a distributed application.
This may be the case if your server is going to be used by many different clients that you do not have control over. It may also be the case if you want to be able to update the server regularly without needing to update the client software.
I can assure you that achieving this low level of coupling is not easy to do . It is critical to follow all of the constraints of REST to succeed. Maintaining a purely stateless connection is difficult. Picking the right media-types and squeezing your data into the formats is tricky. Creating your own media types can be even harder.
Adapting rich server behaviour into the uniform HTTP interface can be confusing and at times appears pedantic in comparison to the relatively straightforward RPC approach.
Despite the difficulties, the benefits are that you have a service that a client developer should be able to easily understand due to the consistent use of the HTTP protocol. The service should be easily discoverable due to hypermedia and the client should be extremely resilient to changes on the server .
The benefits of hypermedia and the avoidance of session state makes load balancing simple and service partitioning feasible . The strict conformance to HTTP rules make the availability of tools like debuggers and caching proxies wonderful thing.
Update
It seems to me that REST is another 'last word of fashion' (or I can be totally wrong because I haven't ever seen REST in practice).
I think REST has become fashionable because people attempting to do SOA type projects have found that using the SOAP stack they are not realizing the benefits that were promised. People keep turning back to the web as an example of simple integration methodologies. Unfortunately, I think people underestimate the amount of planning and foresight that went into creating the web and they oversimplify what needs to be done to allow the kind of serendipitous reuse that does occur on the web.
You say that you have never seen REST in practice, but that cannot possibly be true if you ever use a web browser. The web browser is a REST client.
These may sound like inane questions, but if you know the answer, then you can start to see what REST is all about. Look at StackOverflow for more benefits of REST. When I am looking at a question, I can bookmark that page or send the url to a friend and he can see the same information. He doesn't have to navigate through the site to find that question.
StackOverflow uses a variety of OpenId services for authentication, gravatar.com for avatar images, google-analytics and Quantserve for analytical information. This kind of multi-company integration is the type of thing the SOAP world only dreams of . One of the best examples is the fact that the jQuery libraries that are used to drive the StackOverflow UI are retrieved from Google's Content Delivery Network. The fact that SO could direct the client (ie your web browser) to download code from a third-party site to improve performance is testament to the low coupling between web client and server.
These are examples of a REST architecture at work.
Now some web sites / applications do break the rules of REST and then the browser does not work as expected.
REST is everywhere. It is the part of the web that makes it work well. If you want to build distributed applications that can scale like the web, be resilient to change like the web and promote re-use as the web has done, then follow the same rules they did when building web browsers.
REST was kicked off, to my knowledge, by Roy Fielding's dissertation Architectural Styles and the Design of Network-based Software Architectures, which is worth a read if you haven't looked at it.
At the top of the dissertation is a quote:
Almost everybody feels at peace with nature: listening to the ocean waves against the shore, by a still lake, in a field of grass, on a windblown heath. One day, when we have learned the timeless way again, we shall feel the same about our towns, and we shall feel as much at peace in them, as we do today walking by the ocean, or stretched out in the long grass of a meadow.
— Christopher Alexander, The Timeless Way of Building (1979)
And that really does sum it up there. REST is in many ways more elegant.
SOAP is a protocol on top of HTTP, so it bypasses a lot of HTTP conventions to build new conventions in SOAP, and is in a number of ways redundant with HTTP. HTTP, however, is more than sufficient for retreiving, searching, writing, and deleting information via HTTP, and that's a lot of what REST is. Because REST is built with HTTP instead of on top of it, it also means that software that wants to integrate with it (such as a web browser) does not need to understand SOAP to do so, just HTTP, which has to be the most widely understood and integrated-with protocol in use at this point.
From here:
REST advantages:
Also check this out:
To be fair, REST isn't the best solution for every Web service. Data that needs to be secure should not be sent as parameters in URIs. And large amounts of data, like that in detailed purchase orders, can quickly become cumbersome or even out of bounds within a URI. In these cases, SOAP is indeed a solid solution. But it's important to try REST first and resort to SOAP only when necessary. This helps keep application development simple and accessible.
链接地址: http://www.djcxy.com/p/12338.html