Difference between REST and WebServices

asp.net web-services rest soap

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?

There are potential duplicates of this - REST vs SOAP seems to be a common question (via @John Saunders, good point but rolled back because the comment was made in an edit). While the topic is duplicated I think this question will come up on searches where the others will not, so the question should stay open.

Keith

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.

Ok so REST does everything purely on HTTP where else Web Service does purely on SOAP, on Web Service you need little additional tools to SOAP Marshelling right? Thank you.

About DELETE and PUT, since REST is mostly for machines talking to each other, not having access to those verbs from a browser is maybe not that critical. I think it's pretty important to state the focus on verbs for REST, while SOAP puts the actual commands into the request, instead of the type of the request.

@vs - good point. @Akash Kava - not quite, as SOAP is over HTTP too. You can call either mechanism in Javascript from a simple web page. The important thing about REST is using the convention of HTTP verbs (GET, POST, etc) rather than calling method names read from the WSDL

Small correction for: "SOAP is a protocol for sending/receiving data over HTTP as XML."; SOAP can be over any transport protocols such HTTP, FTP, STMP, JMS etc.

@ShiDoiSi already touched on this but I don't feel it was clear enough for new-comers. To be clear, REST is a common solution for client-server web apps and a user using a web-app via a browser can interact with a RESTful service; they just can't do it directly. It's typically done by tying a JavaScript function to a some HTML-element and that JavaScript in turn calls the RESTful service (ie: PUT, DELETE, etc). This is commonly done using jQuery but there are certainly plenty of other ways to do that.

Andy

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.

Difference between REST and WebServices

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US