Why do we need RESTful Web Services?

Question

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

Answer 1

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture. RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.

Despite being simple, REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture. REST is not a "standard". There will never be a W3C recommendataion for REST, for example. And while there are REST programming frameworks, working with REST is so simple that you can often "roll your own" with standard library features in languages like Perl, Java, or C#.

Answer 2

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.

Answer 3

I can safely say I have spent a lot of time to understand this as a beginner but this is the best link to start with REST from scratch! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

Just to pull you in,

Think of what a "traditional web service" is. It is an interface with exposed "methods." Clients know the methods' name, input and output and hence can call them.

Now imagine an interface that does not expose "methods". Instead, it exposes "objects". So when a client sees this interface, all it sees is one or more "objects". "An object" has no input and output – because "it does not do anything". It is a noun, not a verb. It is "a thing", not "an action".

For example, think of a traditional web service that provides the current weather conditions if you provide it with a city. It probably has a web method like GetWeatherInfo() which takes a city as input and provides weather data as output. It is easy for you so far to understand how a client will consume this web service.

Now imagine, in the place of the above web service, there is a new one that exposes cities as objects. So, when you look at it as a client, instead of GetWeatherInfo(), you see New York, Dallas, Los Angeles, London and so on. And these cities do not have any application specific methods hanging from them - they are apparently like inert gases - they themselves do not react.

You must be thinking – well, how does that help you, as a client, to get to the weather of Dallas? We will get to that in a few moments.

If all you get from a web service is a "set of objects", obviously you need a way to "act on them". The objects themselves have no methods for you to call, so you need a set of actions that you can apply onto these objects. In other words, you need to "apply a verb to the noun". If you see an object, say, an apple, which is "a noun", you can apply "a verb" like eat, to it. But not all verbs can be applied to all nouns. Like, you can drive a car, but cannot drive a television.

Thus, if a web service exposes only objects, and you are asked – well, let us now design a few standard actions or verbs that "all clients can apply to all objects they see", ...

Answer 4

Most of the "pro" answers about REST seem to come from people who have never developed a SOAP web service or client using an environment which supplies appropriate tools for the task. They complain about issues that I've simply never encountered, using Visual Studio .NET and IBM's Rational Web Developer. I suppose that if you have to develop web services or clients in a scripting language, or some other language with little or no tool support, that these are valid complaints.

I also have to admit that several of the "pro" points sound like things that might actually be true - but that I've never seen an example that illustrates their value. In particular, I'd greatly appreciate it if someone would post a comment containing a link to a good example of a REST web service. This should be one that uses multiple levels of resource, possibly in a hierarchy, and which uses media types properly. Maybe if I look at a good example, I'll understand, in which case, I'll come back here and admit it.

Answer 5

From here:

REST advantages:

• Lightweight - not a lot of extra xml markup
• Human Readable Results
• Easy to build - no toolkits required

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.

Answer 6

Here are some ideas:

• REST constrains your service to use a uniform interface. You don't have to waste time daydreaming (or arguing) about all of the possibly ways your service could work - you get right to work identifying the resources in your system. Turns out to be a big job in itself, but fortunately the problems tend to be much-better defined.
• With resources, their associations, and their representations in hand, there's really very little to do in implementing your service because many decisions have been made for you.
• Your system will look very much like other RESTful systems; learning curves for teammates, partners, and clients will be reduced.
• You'll have a common vocabulary to discuss design problems with other developers, and even with those less technically minded (such as customers).
• As Darrel says, because you're using a hypertext-driven design, your service narrows the scope of coupling to just one thing - media types. This helps you as a developer because changes to your system are contained within a narrow band of contact. This helps your clients in that fewer of your changes will break their code.
• Almost every problem you might have in implementing REST can be solved by exposing a new resource or re-thinking your resource model. This focus is, IMO, a big productivity boost.

Bottom line, REST removes many of the most time-consuming and contentious design and implementation decisions from your team's workflow. It shifts your attention from implementing your service to designing it. And it does so without piling gobbledygook onto the HTTP protocol.