0

What is the actual difference b/w WCF vs REST service in a client perspective? I’m aware the following difference WCF Support Multiple Transportation protocols, Hosting, WS-* Features and based on SOAP Message, etc. REST service based on URI’s with HTTP verbs, JSON/XML formats and Hypermedia as State Management, No need of WSDL documents etc. I can easily consume a WCF service from JavaScript client by using JQUERY like “Service Name/Method Name” with JSON DATA , I never faced any complication in regards to SOAP messages, so I think this applicable to any kind of client, I found all REST Gurus are pointing its best suited for any kind of client because there is no complication of SOAP messages . So please guide/suggest me the main advantage of REST in terms of a client? (Forget about WSDL document). Advanced thanks for your great answers

Nabeel
  • 323
  • 3
  • 9
  • 1
    Is this a SOAP vs. REST question? If so, this has been answered many times on SO: [here](http://stackoverflow.com/questions/209905/representational-state-transfer-rest-and-simple-object-access-protocol-soap), for example. – Jonathan W Nov 06 '13 at 06:14
  • Unfortunately, there are huge misconceptions around what REST is and means, and many SO questions and answers contribute to that. The one you linked is a very good example of that. – Pedro Werneck Nov 06 '13 at 11:16

1 Answers1

0

First of all, be aware that what is often called REST isn't really what REST means. I don't know when and how it started, but most people seem to believe that REST is merely mapping the HTTP methods to CRUD, or using JSON, or pretty URIs, or something like that.

The difference is the same you have between a dedicated client application that runs on your device and connects to the server, and a generic client like a browser.

The main advantage of REST on the client side is the lack of coupling between client and server implementation. With SOAP you're bound to an implementation contracted between client and server, and the interaction is expected to break if anyone changes without notice.

With REST, the client shouldn't have any prior information of the service other than the entry point and the available media types available. The server should provide the links the client will navigate to find the resources it's interested, so they can deal much more gracefully with changes. If something changes on the internals, the clients shouldn't even notice. We just get the new links and follow them as usual. If something changes drastically, ideally the clients shouldn't break easily, and can move on to adapt to changes more gradually.

Think about a website, like Stack Overflow itself. When you enter the home, you already know what is a question, an answer and an user, so you know the entry point and the media types. The website provides you with links to questions and users, and you just follow them and act as you want, according to the content provided. You have a generic client, a browser, that works on any website like that, instead of a dedicated client application running on your desktop that connects to the Stack Overflow server. That's the difference. REST is an architecture style that follows the architecture of the web itself.

Pedro Werneck
  • 40,902
  • 7
  • 64
  • 85