Difference between REST and WebServices

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.