Difference between REST and WebServices

What is difference between REST and WebService (SOAP), I looked at the facebook api, they use HTTP headers and some parameters (probably xml or non) and return result in xml, where else SOAP does exactly same, HTTP headers + xml parameters and returns headers + xml.

REST also requires some authenticated token where else SOAP uses http session which is exactly same token used for auth and other information. All I can see that SOAP is little advanced version of REST?

Or are there any other performance considerations? Reading about REST just talks very high level of client server communication but even SOAP does exactly same. Can anyone point me where it can define correct boundry of REST and SOAP.

We use lot of SOAP transparently in .net, however I just want to know is it really worth paying attension to REST where currently everything is running outstandingly smooth.

I know REST is an architecture and SOAP is a protocol but my question is in detail that is currently the ASP.NET WebService implementation of SOAP has REST architecture?

SOAP is a protocol for sending/receiving data over HTTP as XML.

A typical WebService will be a few methods an WSDL that describes how to call it. There's no real convention for how these should be structured, so you always need lots of API documentation.

Typically this will be something like (for ASP.NET):

• HTTP POST to mysite.com/products.asmx/ListAllProducts - returns XML list of products
• HTTP POST to mysite.com/products.asmx/GetProduct - returns XML for product based on SOAP XML in the posted content
• HTTP POST to mysite.com/products.asmx/UpdateProduct - changes product based on SOAP XML in the posted content

REST is more of a convention for structuring all of your methods:

• HTTP GET from mysite.com/products - returns XML or JSON listing all products
• HTTP GET from mysite.com/products/14 - returns XML or JSON for product 14
• HTTP POST to mysite.com/products/14 - changes product 14 to what you post in the HTML form.
• HTTP DELETE to mysite.com/products/14 - removes product 14
• HTTP PUT to mysite.com/products - adds a new product

So REST works more like you'd expect browser URLs to. In that way it's more natural and as a convention is much easier to understand. All REST APIs work in a similar way, so you don't spend as long learning the quirks of each system.

For me a service implemented using a RESTful approach wins over one that uses SOAP or RPC in terms of its accessibility. In a relatively closed system where tooling is available to generate stubs and ties based on a WSDL, this is not terribly important. However, if you want to create services that are accessible and available to a wide range of clients, then the uniformity of REST services and ease with which they can be consumed is a big plus i.e. you don't need a heavy RPC stack, just the ability to make HTTP requests.

Not sure this totally answers your question, but if, as you say, you have a system that works based on SOAP (and you control the client and server) then I don't see any reason to change. Besides, some services will naturally lend themselves more to RPC based access, in which case a SOAP interface will be more appropriate.

In terms of performance, one or more layers would effectively be removed from the client and server technology stacks if you don't use SOAP, so all other things being equal, a service which exposes a RESTful interface will win there.