Restful vs Other Web Services

What does it make Restful webservices different 开发者_开发知识库from the other Web Services like SOAP?

The debate over web services is by no means complete, but there are some elements that stand out.

RESTful web services are a 'family' of web services. Some would call it an architecture.

RESTful web services use the HTTP protocol to perform requests from a web service. They use the HTTP verbs: GET, POST, PUT and DELETE (and others, sometimes). The requests themselves are to URLs which represent resources... sometimes the requests will contain data in the body that could by HTML, JSON, binary data or other.

A purely RESTful web service only requires the URL and the HTTP verb to describe the requested action... the body data is usually a payload to be involved in the requested action... it should not dictate the requested action

SOAP, on the other hand, is actually a protocol. It is usually transported over HTTP, but the HTTP request is just a method to get the SOAP packet to the necessary handler. The contents of the SOAP request describes what the client wants performed. It contains all the necessary information.

They are two very different ways of implementing Web Services. If you ask the question "Which is better" you'll probably get strong opinions from both sides. I suggest you investigate further and make up your own mind.

A RESTful web service (also called a RESTful web API) is a simple web service implemented using HTTP and the principles of REST. Such a web service can be thought about as a collection of resources. The definition of such a web service can be thought of as comprising three aspects:

• The base URI for the web service, such as http://example.com/resources/
• The MIME type of the data supported by the web service. This is often JSON, XML or YAML but can be any other valid MIME type.
• The set of operations supported by the web service using HTTP methods (e.g., POST, GET, PUT or DELETE).

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on eXtensible Markup Language (XML) as its message format, and usually relies on other Application Layer protocols (most notably Remote Procedure Call (RPC) and HTTP) for message negotiation and transmission. This XML based protocol consists of three parts:

• an envelope - which defines what is in the message and how to process it -
• a set of encoding rules for expressing instances of application-defined datatypes,
• and a convention for representing procedure calls and responses.

references:

• http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services
• http://en.wikipedia.org/wiki/SOAP

By the way, a simple google search could provide answers for you...

Ok there is a wealth of knowledge in Stack Overflow on this topic.

I think the best article that articulates the spirit of REST and how it compares against technologies like SOAP is How I explained REST to my wife.

Unlike SOAP, REST is not a standard it's more of an approach that's centred around Resources and things you can do to resources. The HTTP verbs GET, POST, PUT and DELETE are typical actions that you can apply against any resource. SOAP is a standard that ignores these verbs and has invented a more comprehensive protocol that works on top of the most popular verb HTTP POST for maximum interoperability. Most of the time this added complexity is unnecessary and a simple HTTP GET request for a resource would normally suffice over what could be potentially 1KB+ of SOAP+XML to achieve an equivalent result.

You can also check out Roy Fielding's blog (the inventor of REST) for more information about what it means.

RESTful services focus on speed and simplicity, eliminating the overhead of SOAP for the simple transactions that many web services require. However, a service implemented in this way is very HTTP-specific, and you'll have a hard time making use of it outside of that context.

SOAP services offer more out-of-the-box features, the most important (imho, of course) of which is discovery. The ability to add a reference to a SOAP service in just about any dev environment and have it automatically generate a proxy class that will hide the underlying HTTP complexities, even to the point of serializing non-trivial types, is very, very useful.

I feel that both of these approaches to web service development have their place. For AJAX requirements that don't require anything complex, I tend to implement as an HTTP handler (ASP.NET). Anything that needs to be called from another application, or from multiple places within the same app, I implement as a SOAP service because of the protocol encapsulation that it provides, as well as the ability to call the use the underlying object without the HTTP overhead where it makes sense.

1) REST is more simple and easy to use than SOAP 2) REST uses HTTP protocol for producing or consuming web services while SOAP uses XML. 3) REST is lightweight as compared to SOAP and preferred choice in mobile devices and PDA's. 4) REST supports different format like text, JSON and XML while SOAP only support XML. 5) REST web services call can be cached to improve performance.