RESTful vs SOAP based webservices?

 

Folks I recently went thru webservices book which covered SOAP based webservices and RESTful webservices. I am not sure on what parameters I should select one of them as both of them looks similar(even from developer perspective). Here are my points

In SOAP webservices we use WSDL file generated out of webservices and then create client side stubs based on that.

My understanding is that internally stub also will use HTTP protocol to communicate with remote java webservice. Right?

Here there will be SOAP message(XML message) inside HTTP request/response body. so one more layer to drill down while in REST based webservices, HTTP request itself behave as messages. Here we have WADL instead of WSDL. Here also we can create the stubs based on WADL. So every things looks more or less same except the some technical difference consumer connect to producer and how request/reponse are processed.So as per my understanding there is not much difference b/w rest based and soap based webservices from developer point of view (amount of work for developer is almost same).

Is my understanding correct?

Yes probably behind the scenes, probably SOAP is more complicated than REST webservices becoz in SOAP, there is messages inside message(SOAP message is embedded inside HTTP request) but in REST based services, HTTP request itself works as message.

SOAP and REST are aimed at solving a identical set of problems, namely facilitate the interaction between heterogeneous applications in easiest possible manner. Now whether to choose REST or SOAP does not just depend on the amount of development effort. You should consider some of following factors as well,

  • The type of data whether its just simple objects (like name value pair) or very complex schema (or some binary data) to be exchanged between the applications.
  • The consumer of your service. Eg REST are more suitable when you are developing RIA .
  • Security requirement . SOAP by virtue of being standard driven, offers a very fine grain level tuning of security aspect. You can go to an extent of encoding the individual elements of your SOAP xml message. These type of things are not possible in REST (at lest for now).
  • Nowadays notations like JSON are quite popular for lightweight data exchange and many REST service frameworks offers this very easily out of box.
  • Technically, you do not need any framework etc to create a REST web service. I understand that WADL etc came recently to bring in an element of standardization but REST existed even before WADL came. REST is nothing new, its the way web works . REST frameworks make it very easy.

    • SOAP is driven by standards and hence there are more constraints to honor when you work with them. So if you use case is simple (well that's very subjective), go for REST.

    These are two different ways to develop web services... and there is a lot of discussion about their differences (and advantages).

    SOAP web services are much more than the points you refer, actually there is a complete "stack" (WS-*) that aims at standardizing ways to design and implement such web services. This is nice for some systems, but it is "too much" and heavy for others. Behind the scenes HTTP is one popular way to "transport" messages, but it is not the only one, they could be implemented over other protocols. In SOAP you heavily rely on the "WSDL" specification, which indeed can be used to "generate" server and client code. In these specification you think very much about "operations", things to be done on the web service.

    On the other hand on REST we think more about "resources" (described by a given URI), and then over it we perform the HTTP operations. There is not so much the notion of specification as in SOAP web services, although WADL exists. Actually a big difference, and which people do not think much about (but actually is part of the core of REST principles), is the idea that in REST you have the so called "hyperlinks", which aim at allow client-server to communicate "state" (where to go next), which is not so "dynamically" handled in SOAP web services.

    Bottom line, for developers point of view: SOAP does have quite a lot of good tooling (eg: all Eclipse Web services tools), however it tends to be a bit cumbersome and a lot of "code". REST development is normally cleaner and simpler. I do think both are solutions that be used as function of the situation you are dealing with, you should not "pick one". For example, if you have a huge enterprise applications, with a lot of parts and interdependencies, transactions handling, etc., probably SOAP Web services with WSDL (contracts) is the way to go. On the other hand if you are exposing one web service (or API) to clients, without many interdependencies, probably REST is the most interesting (you can see this in the changes we got on the last 5 years or so, where all major Web APIS - google, twitter, etc., all are now exposed as REST web services).

    There are no big differences (especially from developers view).

    The only real difference is that SOAP is standardized with the WS-* recommendations. Also in SOAP there are possibilities to create transactions and to secure the message itself based on the standards. So for interoperability SOAP has advantages based on this.

    链接地址: http://www.djcxy.com/p/71390.html

    上一篇: 从iOS应用程序调用Web服务

    下一篇: 基于RESTful vs基于SOAP的Web服务？