WSDL vs REST Pros and Cons

Question

Related      Why would one use REST instead of Web services    When deciding whether to implement a web service using SOAP or REST  by which I mean HTTP XML in a RESTful manner  what should I be aware of and what should I be thinking of  I presume that this isn t a one size fits all thing so how do I choose which to use

User · Answer

SOAP  It can be transported via SMTP also  means we can invoke the service using Email simple text format also  It needs additional framework engine should be in web service consumer machine to convert SOAP message to respective objects structure in various languages    REST  Now WSDL2 0 supports to describe REST web service also  We can use when you want to make your service as lightweight  example calling from mobile devices like cell phone  pda etc

User · Answer

Regarding WSDL  meaning  SOAP   as being  heavy-weight   Heavy matters how  If the toolset is doing all the  heavy lifting  for you  then why does it matter   I have never yet needed to consume a complicated REST API  When I do  I expect I ll wish for a WSDL  which my tools will gladly convert into a set of proxy classes  so I can just call what appear to be methods  Instead  I suspect that in order to consume a non-trivial REST-based API  it will be necessary to write by hand a substantial amount of  light-weight  code   Even when that s all done  you still will have translated human-readable documentation into code  with all the attendant risk that the humans read it wrong  Since WSDL is a machine-readable description of the service  it s much harder to  read it wrong      Just a note  since this post  I have had the opportunity to work with a moderately complicated REST service  I did  indeed  wish for a WSDL or the equivalent  and I did  indeed  have to write a lot of code by hand  In fact  a substantial part of the development time was spent removing the code duplication of all the code that called different service operations  by hand

User · Answer

for enterprise systems in which your system is confined within your corporations  its easier and proper to use soap because you are almost in control of clients  it s easier since there a variety of tools which creates classes  proxies  and looks like you are doing your regular OOP which matches your java or  net  environment  in which most corporates use    I would use REST for internet facing applications for exposing interfaces  like twitter api  since clients can be using javascripts or html or others in which typing is not strict  REST being more liberal makes more sense   Also for internet facing clients  world wide web   its easier to parse json or xml coming out of a rest interface rather than a purely xml coming from a soap interface  it s hard to use proxies on javascript and javascript does not naturally support objects  If you are using REST with javascript  you would just usually parse the json string and you re off  internet facing interfaces are usually very simple  so most of the time its simple parsing  and does not usually demand consistency that is why REST is adequate enough    For enterprise applications I don t think REST is adequate because transactions  security  strict typing  schemas play a very important in enterprise applications development that is why SOAP is more suited for them   My conclusion is that SOAP is for Enterprise systems  REST is for the Internet or WWW   You can use it interchangeably but you may find yourself having a difficult time eventually not using the correct tool for the job   sorry for my bad english

User · Answer

The previous answers contain a lot of information  but I think there is a philosophical difference that hasn t been pointed out  SOAP was the answer to  how to we create a modern  object-oriented  platform and protocol independent successor to RPC    REST developed from the question   how to we take the insights that made HTTP so successful for the web  and use them for distributed computing    SOAP is a about giving you tools to make distributed programming look like     programming  REST tries to impose a style to simplify distributed interfaces  so that distributed resources can refer to each other like distributed html pages can refer to each other  One way it does that is attempt to  mostly  restrict operations to  CRUD  on resources  create  read  update  delete    REST is still young -- although it is oriented towards  human readable  services  it doesn t rule out introspection services  etc  or automatic creation of proxies  However  these have not been standardized  as I write   SOAP gives you these things  but  IMHO  gives you  only  these things  whereas the style imposed by REST is already encouraging the spread of web services because of its simplicity  I would myself encourage newbie service providers to choose REST unless there are specific SOAP-provided features they need to use   In my opinion  then  if you are implementing a  greenfield  API  and don t know that much about possible clients  I would choose REST as the style it encourages tends to help make interfaces comprehensible  and easy to develop to  If you know a lot about client and server  and there are specific SOAP tools that will make life easy for both  then I wouldn t be religious about REST  though

User · Answer

I know that this discussion is an old one  but after reading all the answers and commented  I believe that everyone missed the most important point about the difference between the 2 systems  SOAP uses complex types to not only give you the data  but validate it and keep it in the strict type designation it was defined for  A WSDL tells you what the data format is  what the data type is  allows you to add reg-ex pattern-style rules  and defines how many times a piece of data must be  and may be  allowed in a request response  Rest on the other-hand has none of these mechanisms   SOAP is complex and heavy because it allows you to send complex heavy hierarchical data  REST is plain text  with the origin and endpoint sorting out the rules   SOAP is business independent  because it has all the data rules embedded in the document   The difference between SOAP and REST is that SOAP is a self-contained business oriented schema  REST is a text document

User · Answer

The two protocols have very different uses in the real world   SOAP using WSDL  is a heavy-weight XML standard that is centered around document passing   The advantage with this is that your requests and responses can be very well structured  and can even use a DTD   The downside is it is XML  and is very verbose   However  this is good if two parties need to have a strict contract say for inter-bank communication    SOAP also lets you layer things like WS-Security on your documents  SOAP is generally transport-agnostic  meaning you don t necessarily need to use HTTP   REST is very lightweight  and relies upon the HTTP standard to do it s work   It is great to get a useful web service up and running quickly   If you don t need a strict  API definition  this is the way to go   Most web services fall into this category   You can version your API so that updates to the API do not break it for people using old versions as long as they specify a version    REST essentially requires HTTP  and is format-agnostic meaning you can use XML  JSON  HTML  whatever    Generally I use REST  because I don t need fancy WS-  features   SOAP is good though if you want computers to understand your webservice using a WSDL   REST specifications are generally human-readable only

User · Answer

You can easily transition your WSDL-spewing WCF web components to other uses just by changing your configuration settings   You can go across HTTP and then also named pipes  tcp  custom protocols  etc without having to change your code   I believe WCF components may also be easier to set up for stuff like security  two-way calling  transactions  concurrency  etc   REST pretty much limits you to HTTP  which is fine in many cases

User · Answer

The toolset on the client side would be one  And the familiarity with SOAP services the other  More and more services are going the RESTful route these days  and testing such services can be done with simple cURL examples   Although  it s not all that difficult to implement both methods and allow for the widest utilization from clients   If you need to pick one  I d suggest REST  it s easier

User · Answer

To me we should be careful when we use the word web service  We should all the time specify if we are speaking of SOAP web service  REST web service or other kind of web services because we are speaking about different things here and people don t understand anymore if we named all of them web services   Basically SOAP web services are very well established for years and they follow a strict specification that describe how to communicate with them based on the SOAP specification  Now REST web services are a bit newer and basically looks like simpler because they are not using any communication protocol  Basically what you send and receive when you use a REST web service is plain XML  People like it because they can parse the xml the way they want without having to deal with a more sophisticated communication protocol like SOAP   To me REST services are almost like if you would create a servlet instead of a SOAP web service  The servlet get data in and return data out  The format of the data are xml based  We can also imagine to use something else than xml if we want  For instance tags could be used instead of xml and that would be not REST anymore but something else  Could be even lighter in term of weight because xml is not light by nature   Would we call that still a web service  Yes we could but that will not follow any current standard and this is the main issue here if we start to call everything web services but we can do it the way we want then we are loosing on the interoperability side of the things  That means that the format of the data that is exchanged with the web service is not standardized anymore  That requires then that server and client agree on the format of the data whereas with SOAP this is all predefined already and server and client can interoperate without to know each other because they follow the same standard   What people don t like with SOAP is that they have hard time to understand it and they cannot generate the queries manually  Computers can do that very well however so this is where we need to be clear  are web services queries and response supposed to be used directly by the end users or do we agree that web services are underneath API called by computer systems based on some normalized standards

User · Answer

REST is not a protocol  It s an architectural style  Or a paradigm if you want  That means that it s a lot looser defined that SOAP is  For basic CRUD  you can lean on standard protocols such as Atompub  but for most services you ll have more commands than just that   As a consumer  SOAP can be a blessing or a curse  depending on the language support  Since SOAP is very much modelled on a strictly typed system  it works best with statically typed languages  For a dynamic language it can easily become crufty and superfluous  In addition  the client-library support isn t that good outside the world of Java and  NET

User · Answer

The following links provide useful information about WSDL vs REST including Pros and Cons  A couple of key points are that   1  SOAP was designed for a distributed computing environment where as REST was designed for a point to point environment   2  WADL can be used to define the interface for REST services   http   www ajaxonomy com 2008 xml web-services-part-1-soap-vs-rest http   ajaxonomy com 2008 xml web-services-part-2-wsdl-and-wadl

User · Answer

In defence of REST it closely follows the principles of HTTP and addressability e g  read operations use GET  update operations use POST etc  I find this to be a far cleaner approach  The Oreilly book RESTful Web Services explains this far better than I can  if you read it I think you would prefer the REST approach

User · Answer

This probably really belongs as comments in several of the above posts  but I don t yet have the rep to do that  so here goes   I think it is interesting that a lot of the pros and cons often cited for SOAP and REST have  IMO  very little to do with the actual values or limits of the two technologies   Probably the most cited pro for REST is that it is  light-weight  or tends to be more  human readable    At one level this is certainly true  REST does have a lower barrier to entry - there is less required structure than SOAP  though I agree with those who have said that good tooling is largely the answer here - too bad much of the SOAP tooling is pretty dreadful      Beyond that initial entry cost however  I think the REST impression comes from a combination of the form of the request URLs and the complexity of the data exchanged by most REST services   REST tends to encourage simpler  more human readable request URLs and the data tends to be more digestable as well   To what extent however are these inherent to REST and to what extent are they merely accidental   The simpler URL structure is a direct result of the architecture - but it could be equally well applied to SOAP based services   The more digestable data is more likely to be a result of the lack of any defined structure   This means you d better keep your data formats simple or you are going to be in for a lot of work   So here SOAP s additional structure  which should be a benefit is actually enabling sloppy design and that sloppy design then gets used as a dig against the technology   So for use in the exchange of structured data between computer systems I m not sure that REST is inherently better than SOAP  or visa-versa   they are just different   I think the comparison above of REST vs SOAP to dynamic vs  static typing is a good one   Where dyanmic languages tend to run in to trouble is in long term maintenance and upkeep of a system  and by long term I m not talking a year or 2  I m talking 5 or 10    It will be interesting to see if REST runs into the same challenges over time   I tend to think it will so if I were building a distributed  information processing system I would gravitate to SOAP as the communication mechanism  also because of the tranmission and application protocol layering and flexibility that it affords as has been mentioned above    In other places though REST seems more appropriate   AJAX between the client and its server  regardless of payload  is one major example   I don t have much care for the longevity of this type of connection and ease of use and flexibility are at a premimum   Similarly if I needed quick access to some external service and I didn t think I was going to care about the maintainability of the interaction over time  again I m assuming this is where REST is going to end up costing me more  one way or another   then I might choose REST just so I could get in and out quickly   Anyway  they are both viable technologies and depending on what tradeoffs you want to make for a given application they can serve you well  or poorly

[web-services] WSDL vs REST Pros and Cons

Examples related to web-services

Examples related to rest

Examples related to wsdl