SOAP or REST for Web Services

Question

Is REST a better approach to doing Web Services or is SOAP   Or are they different tools for different problems    Or is it a nuanced issue - that is  is one slightly better in certain arenas than another  etc   I would especially appreciate information about those concepts and their relation to the PHP-universe and also modern high-end web-applications

User · Answer

REST is a fundamentally different paradigm from SOAP. A good read on REST can be found here: How I explained REST to my wife.

If you don't have time to read it, here's the short version: REST is a bit of a paradigm shift by focusing on "nouns", and restraining the number of "verbs" you can apply to those nouns. The only allowed verbs are "get", "put", "post" and "delete". This differs from SOAP where many different verbs can be applied to many different nouns (i.e. many different functions).

For REST, the four verbs map to the corresponding HTTP requests, while the nouns are identified by URLs. This makes state management much more transparent than in SOAP, where its often unclear what state is on the server and what is on the client.

In practice though most of this falls away, and REST usually just refers to simple HTTP requests that return results in JSON, while SOAP is a more complex API that communicates by passing XML around. Both have their advantages and disadvantages, but I've found that in my experience REST is usually the better choice because you rarely if ever need the full functionality you get from SOAP.

User · Answer

An old question but still relevant today    due to so many developers in the enterprise space still using it   My work involves designing and developing IoT  Internet of Things  solutions  Which includes developing code for small embedded devices that communicate with the Cloud    It is clear REST is now widely accepted and useful  and pretty much the defacto standard for the web  even Microsoft has REST support included throughout Azure  If I needed to rely on SOAP I could not do what I need to do  as is just too big  bulky and annoying for small embedded devices   REST is simple and clean and small  Making it ideal for small embedded devices  I always scream when I am working with a web developer who sends me a WSDLs  As I will have to begin an education campaign about why this just isn t going to work and why they are going to have to learn REST

User · Answer

Don t overlook XML-RPC   If you re just after a lightweight solution then there s a great deal to be said for a protocol that can be defined in a couple of pages of text and implemented in a minimal amount of code   XML-RPC has been around for years but went out of fashion for a while - but the minimalist appeal seems to be giving it something of a revival of late

User · Answer

One thing that hasn t been mentioned is that a SOAP envelope can contain headers as well as body parts  This lets you use the full expressiveness of XML to send and receive out of band information  REST  as far as I know  limits you to HTTP Headers and result codes    otoh  can you use cookies with a REST service to send  header -type out of band data

User · Answer

I think that both has its own place  In my opinion   SOAP  A better choice for integration between legacy critical systems and a web web-service system  on the foundation layer  where WS-  make sense  security  policy  etc      RESTful  A better choice for integration between websites  with public API  on the TOP of layer  VIEW  ie  javascripts taking calls to URIs

User · Answer

I am looking at the same issue  Seems to me that actually REST is quick and easy and good for lightweight calls and responses and great for debugging  what could be better than pumping a URL into a browser and seeing the response    However where REST seems to fall down is to do with the fact that its not a standard  although it is comprised of standards   Most programming libraries have a way of inspecting  a WSDL to automatically generate the client code needed to consume a SOAP based services  Thus far consuming REST based web services seems a more adhoc approach of writing an interface to match the calls that are possible  Making a manual http request then parsing the response  This in itself can be dangerous    The beauty of SOAP is that once a WSDL is issued then business  can structure their logic aorund that set contract any change to the interface will change the wsdl  There isnt any room for manouvre  You can validate all requests against that WSDL  However because a WSDL doesnt properly describe a REST service then you have no defined way of agreeing on the interface for communication   From a business perspective this does seem to leave the communication open to interpretation and change which seems like a bad idea   The top  Answer  in this thread seems to say that SOAP stands for Simple Object-oriented Access Protocol  however looking at wiki the O means Object not Object-oriented  They are different things   I know this post is very old but thought I should respond with my own findings

User · Answer

Most of the applications I write are server-side C  or Java  or desktop applications in WinForms or WPF   These applications tend to need a richer service API than REST can provide   Plus  I don t want to spend any more than a couple minutes creating my web service client   The WSDL processing client generation tools allow me to implement my client and move on to adding business value   Now  if I were writing a web service explicitly for some javascript ajax calls  it d probably be in REST  just for the sake knowing the client technology and leveraging JSON   In my opinion  web service APIs used from javascript probably shouldn t be very complex  as that type of complexity seems to be better handled server-side   With that said  there some SOAP clients for javascript  I know jQuery has one   Thus  SOAP can be leveraged from javascript  just not as nicely as a REST service returning JSON strings  So if I had a web service that I wanted to be complex enough that it was flexible for an arbitrary number of client technologies and uses  I d go with SOAP

User · Answer

REST is an architecture  SOAP is a protocol   That s the first problem   You can send SOAP envelopes in a REST application   SOAP itself is actually pretty basic and simple  it s the WSS-  standards on top of it that make it very complex   If your consumers are other applications and other servers  there s a lot of support for the SOAP protocol today  and the basics of moving data is essentially a mouse-click in modern IDEs   If your consumers are more likely to be RIAs or Ajax clients  you will probably want something simpler than SOAP  and more native to the client  notably JSON    JSON packets sent over HTTP is not necessarily a REST architecture  it s just messages to URLs  All perfectly workable  but there are key components to the REST idiom  It is easy to confuse the two however  But just because you re talking HTTP requests does not necessarily mean you have a REST architecture  You can have a REST application with no HTTP at all  mind  this is rare    So  if you have servers and consumers that are  comfortable  with SOAP  SOAP and WSS stack can serve you well  If you re doing more ad hoc things and want to better interface with web browsers  then some lighter protocol over HTTP can work well also

User · Answer

REST is an architecture  SOAP is a protocol   That s the first problem   You can send SOAP envelopes in a REST application   SOAP itself is actually pretty basic and simple  it s the WSS-  standards on top of it that make it very complex   If your consumers are other applications and other servers  there s a lot of support for the SOAP protocol today  and the basics of moving data is essentially a mouse-click in modern IDEs   If your consumers are more likely to be RIAs or Ajax clients  you will probably want something simpler than SOAP  and more native to the client  notably JSON    JSON packets sent over HTTP is not necessarily a REST architecture  it s just messages to URLs  All perfectly workable  but there are key components to the REST idiom  It is easy to confuse the two however  But just because you re talking HTTP requests does not necessarily mean you have a REST architecture  You can have a REST application with no HTTP at all  mind  this is rare    So  if you have servers and consumers that are  comfortable  with SOAP  SOAP and WSS stack can serve you well  If you re doing more ad hoc things and want to better interface with web browsers  then some lighter protocol over HTTP can work well also

User · Answer

It s nuanced   If you need to have other systems interface with your services  than a lot of clients will be happier with SOAP  due to the layers of  verification  you have with the contracts  WSDL  and the SOAP standard   For day-to-day systems calling into systems  I think that SOAP is a lot of unnecessary overhead when a simple HTML call will do

User · Answer

I know this is an old question but I have to post my answer - maybe someone will find it useful  I can t believe how many people are recommending REST over SOAP  I can only assume these people are not developers or have never actually implemented a REST service of any reasonable size  Implementing a REST service takes a LOT longer than implementing a SOAP service  And in the end it comes out a lot messier  too  Here are the reasons I would choose SOAP 99  of the time   1  Implementing a REST service takes infinitely longer than implementing a SOAP service  Tools exist for all modern languages frameworks platforms to read in a WSDL and output proxy classes and clients  Implementing a REST service is done by hand and - get this - by reading documentation  Furthermore  while implementing these two services  you have to make  guesses  as to what will come back across the pipe as there is no real schema or reference document   2  Why write a REST service that returns XML anyway  The only difference is that with REST you don t know the types each element attribute represents - you are on your own to implement it and hope that one day a string doesn t come across in a field you thought was always an int  SOAP defines the data structure using the WSDL so this is a no-brainer   3  I ve heard the complaint that with SOAP you have the  overhead  of the SOAP Envelope  In this day and age  do we really need to worry about a handful of bytes   4  I ve heard the argument that with REST you can just pop the URL into the browser and see the data  Sure  if your REST service is using simple or no authentication  The Netflix service  for instance  uses OAuth which requires you to sign things and encode things before you can even submit your request   5  Why do we need a  readable  URL for each resource  If we were using a tool to implement the service  do we really care about the actual URL   Need I go on

User · Answer

SOAP is useful from a tooling perspective because the WSDL is so easily consumed by tools   So  you can get Web Service clients generated for you in your favorite language   REST plays well with AJAX y web pages   If you keep your requests simple  you can make service calls directly from your JavaScript  and that comes in very handy   Try to stay away from having any namespaces in your response XML  I ve seen browsers choke on those   So  xsi type is probably not going to work for you  no overly complex XML Schemas   REST tends to have better performance as well   CPU requirements of the code generating REST responses tend to be lower than what SOAP frameworks exhibit   And  if you have your XML generation ducks lined up on the server side  you can effectively stream XML out to the client   So  imagine you re reading rows of database cursor   As you read a row  you format it as an XML element  and you write that directly out to the service consumer   This way  you don t have to collect all of the database rows in memory before starting to write your XML output - you read and write at the same time   Look into novel templating engines or XSLT to get the streaming to work for REST   SOAP on the other hand tends to get generated by tool-generated services as a big blob and only then written   This is not an absolute truth  mind you  there are ways to get streaming characteristics out of SOAP  like by using attachments     My decision making process is as follows   if I want my service to be easily tooled by consumers  and the messages I write will be medium-to-small-ish  10MB or less   and I don t mind burning some extra CPU cycles on the server  I go with SOAP   If I need to serve to AJAX on web browsers  or I need the thing to stream  or my responses are gigantic  I go REST   Finally  there are lots of great standards built up around SOAP  like WS-Security and getting stateful Web Services  that you can plug in to if you re using the right tools   That kind of stuff really makes a difference  and can help you satisfy some hairy requirements

User · Answer

It s a good question    I don t want to lead you astray  so I m open to other people s answers as much as you are   For me  it really comes down to cost of overhead and what the use of the API is   I prefer consuming web services when creating client software  however I don t like the weight of SOAP   REST  I believe  is lighter weight but I don t enjoy working with it from a client perspective nearly as much   I m curious as to what others think

User · Answer

REST is an architecture invented by Roy Fielding and described in his dissertation Architectural Styles and the Design of Network-based Software Architectures  Roy is also the main author of HTTP - the protocol that defines document transfer over the World Wide Web  HTTP is a RESTful protocol  When developers talk about  using REST Web services  it is probably more accurate to say  using HTTP    SOAP is a XML-based protocol that tunnels inside an HTTP request response  so even if you use SOAP  you are using REST too  There is some debate over whether SOAP adds any significant functionality to basic HTTP   Before authoring a Web service  I would recommend studying HTTP  Odds are your requirements can be implemented with functionality already defined in the spec  so other protocols won t be needed

User · Answer

SOAP currently has the advantage of better tools where they will generate a lot of the boilerplate code for both the service layer as well as generating clients from any given WSDL    REST is simpler  can be easier to maintain as a result  lies at the heart of Web architecture  allows for better protocol visibility  and has been proven to scale at the size of the WWW itself  Some frameworks out there help you build REST services  like Ruby on Rails  and some even help you with writing clients  like ADO NET Data Services  But for the most part  tool support is lacking

User · Answer

In sense with  PHP-universe  PHP support for any advanced SOAP sucks big time  You will end up using something like http   wso2 com products web-services-framework php  as soon as you cross the basic needs  even to enable WS-Security or WS-RM no inbuilt support   SOAP envelope creation I feel is lot messy in PHP  the way it creates namespaces  xsd nil  xsd anytype and old styled soap Services which use SOAP Encoding  God knows how s that different  with in SOAP messages    Avoid all this mess by sticking to REST  REST is nothing really big we have been using it since the start of WWW  We realized only when this http   www ics uci edu  fielding pubs dissertation top htm paper came out it shows how can we use HTTP capabilities to implement RESTFul Services  HTTP is inherently REST  that doesn t mean just using HTTP makes your services RESTFul    SOAP neglects the core capabilities of HTTP and considers HTTP just as an transport protocol  hence it is transport protocol independent in theory  in practical it s not the case have you heard of SOAP Action header  if not google it now     With JSON adaption increasing and HTML5 with javascript maturing REST with JSON has become the most common way of dealing with services  JSON Schema has also been defined can be used for enterprise level solutions  still in early stages  along with WADL if needed    PHP support for REST and JSON is definitely better than existing inbuilt SOAP support it has    Adding few more BUZZ words here SOA  WOA  ROA   http   blog dhananjaynene com 2009 06 rest-soa-woa-or-roa   http   www scribd com doc 15657444 REST-White-Paper  by the way I do love SOAP especially for the WS-Security spec  this is one good spec and if someone thinking in Enterprise JSON adaption definetly need to come with some thing similar for JSON  like field level encryption etc

User · Answer

It s nuanced   If you need to have other systems interface with your services  than a lot of clients will be happier with SOAP  due to the layers of  verification  you have with the contracts  WSDL  and the SOAP standard   For day-to-day systems calling into systems  I think that SOAP is a lot of unnecessary overhead when a simple HTML call will do

User · Answer

REST is a fundamentally different paradigm from SOAP. A good read on REST can be found here: How I explained REST to my wife.

If you don't have time to read it, here's the short version: REST is a bit of a paradigm shift by focusing on "nouns", and restraining the number of "verbs" you can apply to those nouns. The only allowed verbs are "get", "put", "post" and "delete". This differs from SOAP where many different verbs can be applied to many different nouns (i.e. many different functions).

For REST, the four verbs map to the corresponding HTTP requests, while the nouns are identified by URLs. This makes state management much more transparent than in SOAP, where its often unclear what state is on the server and what is on the client.

In practice though most of this falls away, and REST usually just refers to simple HTTP requests that return results in JSON, while SOAP is a more complex API that communicates by passing XML around. Both have their advantages and disadvantages, but I've found that in my experience REST is usually the better choice because you rarely if ever need the full functionality you get from SOAP.

User · Answer

An old question but still relevant today    due to so many developers in the enterprise space still using it   My work involves designing and developing IoT  Internet of Things  solutions  Which includes developing code for small embedded devices that communicate with the Cloud    It is clear REST is now widely accepted and useful  and pretty much the defacto standard for the web  even Microsoft has REST support included throughout Azure  If I needed to rely on SOAP I could not do what I need to do  as is just too big  bulky and annoying for small embedded devices   REST is simple and clean and small  Making it ideal for small embedded devices  I always scream when I am working with a web developer who sends me a WSDLs  As I will have to begin an education campaign about why this just isn t going to work and why they are going to have to learn REST

User · Answer

I m sure Don Box created SOAP as a joke -  look you can call RPC methods over the web  and today groans when he realises what a bloated nightmare of web standards it has become  -   REST is good  simple  implemented everywhere  so more a  standard  than the standards  fast and easy  Use REST

User · Answer

i create a benchmark for find which of them are faster  i see this result   for 1000 requests     REST took 3 second SOAP took 7 second   for 10 000 requests     REST took 33 second SOAP took 69 second   for 1 000 000 requests     REST took 62 second SOAP took 114 second

User · Answer

I built one of the first SOAP servers  including code generation and WSDL generation  from the original spec as it was being developed  when I was working at Hewlett-Packard  I do NOT recommend using SOAP for anything   The acronym  SOAP  is a lie  It is not Simple  it is not Object-oriented  it defines no Access rules  It is  arguably  a Protocol  It is Don Box s worst spec ever  and that s quite a feat  as he s the man who perpetrated  COM    There is nothing useful in SOAP that can t be done with REST for transport  and JSON  XML  or even plain text for data representation  For transport security  you can use https  For authentication  basic auth  For sessions  there s cookies  The REST version will be simpler  clearer  run faster  and use less bandwidth   XML-RPC clearly defines the request  response  and error protocols  and there are good libraries for most languages  However  XML is heavier than you need for many tasks

User · Answer

I built one of the first SOAP servers  including code generation and WSDL generation  from the original spec as it was being developed  when I was working at Hewlett-Packard  I do NOT recommend using SOAP for anything   The acronym  SOAP  is a lie  It is not Simple  it is not Object-oriented  it defines no Access rules  It is  arguably  a Protocol  It is Don Box s worst spec ever  and that s quite a feat  as he s the man who perpetrated  COM    There is nothing useful in SOAP that can t be done with REST for transport  and JSON  XML  or even plain text for data representation  For transport security  you can use https  For authentication  basic auth  For sessions  there s cookies  The REST version will be simpler  clearer  run faster  and use less bandwidth   XML-RPC clearly defines the request  response  and error protocols  and there are good libraries for most languages  However  XML is heavier than you need for many tasks

User · Answer

Listen to this podcast to find out  If you want to know the answer without listening  then OK  its REST   But I really do recommend listening

User · Answer

Don t overlook XML-RPC   If you re just after a lightweight solution then there s a great deal to be said for a protocol that can be defined in a couple of pages of text and implemented in a minimal amount of code   XML-RPC has been around for years but went out of fashion for a while - but the minimalist appeal seems to be giving it something of a revival of late

User · Answer

I d recommend you go with REST first - if you re using Java look at JAX-RS and the Jersey implementation  REST is much simpler and easy to interop in many languages    As others have said in this thread  the problem with SOAP is its complexity when the other WS-  specifications come in and there are countless interop issues if you stray into the wrong parts of WSDL  XSDs  SOAP  WS-Addressing etc   The best way to judge the REST v SOAP debate is look on the internet - pretty much all the big players in the web space  google  amazon  ebay  twitter et al - tend to use and prefer RESTful APIs over the SOAP ones   The other nice approach to going with REST is that you can reuse lots of code and infratructure between a web application and a REST front end  e g  rendering HTML versus XML versus JSON of your resources is normally pretty easy with frameworks like JAX-RS and implicit views - plus its easy to work with RESTful resources using a web browser

User · Answer

SOAP embodies a service-oriented approach to Web services     one in which methods  or verbs  are the primary way you interact with the service  REST takes a resource-oriented approach in which the object  or the noun  takes center stage

User · Answer

SOAP is useful from a tooling perspective because the WSDL is so easily consumed by tools   So  you can get Web Service clients generated for you in your favorite language   REST plays well with AJAX y web pages   If you keep your requests simple  you can make service calls directly from your JavaScript  and that comes in very handy   Try to stay away from having any namespaces in your response XML  I ve seen browsers choke on those   So  xsi type is probably not going to work for you  no overly complex XML Schemas   REST tends to have better performance as well   CPU requirements of the code generating REST responses tend to be lower than what SOAP frameworks exhibit   And  if you have your XML generation ducks lined up on the server side  you can effectively stream XML out to the client   So  imagine you re reading rows of database cursor   As you read a row  you format it as an XML element  and you write that directly out to the service consumer   This way  you don t have to collect all of the database rows in memory before starting to write your XML output - you read and write at the same time   Look into novel templating engines or XSLT to get the streaming to work for REST   SOAP on the other hand tends to get generated by tool-generated services as a big blob and only then written   This is not an absolute truth  mind you  there are ways to get streaming characteristics out of SOAP  like by using attachments     My decision making process is as follows   if I want my service to be easily tooled by consumers  and the messages I write will be medium-to-small-ish  10MB or less   and I don t mind burning some extra CPU cycles on the server  I go with SOAP   If I need to serve to AJAX on web browsers  or I need the thing to stream  or my responses are gigantic  I go REST   Finally  there are lots of great standards built up around SOAP  like WS-Security and getting stateful Web Services  that you can plug in to if you re using the right tools   That kind of stuff really makes a difference  and can help you satisfy some hairy requirements

User · Answer

Listen to this podcast to find out  If you want to know the answer without listening  then OK  its REST   But I really do recommend listening

User · Answer

1 From my experience  I would say REST gives you option to access the URL which is already built  eg-  a word search in google  That URL could be used as webservice for REST   In SOAP  you can create your own web service and access it through SOAP client    REST supports text JSON XML format  Hence more versatile for communicating between two applications  While SOAP supports only XML format for message communication

User · Answer

It s a good question    I don t want to lead you astray  so I m open to other people s answers as much as you are   For me  it really comes down to cost of overhead and what the use of the API is   I prefer consuming web services when creating client software  however I don t like the weight of SOAP   REST  I believe  is lighter weight but I don t enjoy working with it from a client perspective nearly as much   I m curious as to what others think

User · Answer

It s nuanced   If you need to have other systems interface with your services  than a lot of clients will be happier with SOAP  due to the layers of  verification  you have with the contracts  WSDL  and the SOAP standard   For day-to-day systems calling into systems  I think that SOAP is a lot of unnecessary overhead when a simple HTML call will do

User · Answer

Don t overlook XML-RPC   If you re just after a lightweight solution then there s a great deal to be said for a protocol that can be defined in a couple of pages of text and implemented in a minimal amount of code   XML-RPC has been around for years but went out of fashion for a while - but the minimalist appeal seems to be giving it something of a revival of late

User · Answer

Quick lowdown for 2012 question   Areas that REST works really well for are    Limited bandwidth and resources  Remember the return structure is really in any format  developer defined   Plus  any browser can be used because the REST approach uses the standard  GET   PUT   POST  and  DELETE  verbs  Again  remember that REST can also use the  XMLHttpRequest  object that most modern browsers support today  which adds an extra bonus of AJAX  Totally stateless operations   If an operation needs to be continued  then REST is not the best approach and SOAP may fit it better  However  if you need stateless CRUD  Create  Read  Update  and Delete  operations  then REST is it  Caching situations   If the information can be cached because of the totally stateless operation of the REST approach  this is perfect That covers a lot of solutions in the above three     So why would I even consider SOAP  Again  SOAP is fairly mature and well-defined and does come with a complete specification  The REST approach is just that  an approach and is wide open for development  so if you have the following then SOAP is a great solution    Asynchronous processing and invocation   If your application needs a guaranteed level of reliability and security then SOAP 1 2 offers additional standards to ensure this type of operation  Things like WSRM     WS-Reliable Messaging  Formal contracts   If both sides  provider and consumer  have to agree on the exchange format then SOAP 1 2 gives the rigid specifications for this type of interaction  Stateful operations  If the application needs contextual information and conversational state management then SOAP 1 2 has the additional specification in the WS  structure to support those things  Security  Transactions  Coordination  etc   Comparatively  the REST approach would make the developers build this custom plumbing    http   www infoq com articles rest-soap-when-to-use-each

User · Answer

1 From my experience  I would say REST gives you option to access the URL which is already built  eg-  a word search in google  That URL could be used as webservice for REST   In SOAP  you can create your own web service and access it through SOAP client    REST supports text JSON XML format  Hence more versatile for communicating between two applications  While SOAP supports only XML format for message communication

User · Answer

I am looking at the same issue  Seems to me that actually REST is quick and easy and good for lightweight calls and responses and great for debugging  what could be better than pumping a URL into a browser and seeing the response    However where REST seems to fall down is to do with the fact that its not a standard  although it is comprised of standards   Most programming libraries have a way of inspecting  a WSDL to automatically generate the client code needed to consume a SOAP based services  Thus far consuming REST based web services seems a more adhoc approach of writing an interface to match the calls that are possible  Making a manual http request then parsing the response  This in itself can be dangerous    The beauty of SOAP is that once a WSDL is issued then business  can structure their logic aorund that set contract any change to the interface will change the wsdl  There isnt any room for manouvre  You can validate all requests against that WSDL  However because a WSDL doesnt properly describe a REST service then you have no defined way of agreeing on the interface for communication   From a business perspective this does seem to leave the communication open to interpretation and change which seems like a bad idea   The top  Answer  in this thread seems to say that SOAP stands for Simple Object-oriented Access Protocol  however looking at wiki the O means Object not Object-oriented  They are different things   I know this post is very old but thought I should respond with my own findings

User · Answer

I think that both has its own place  In my opinion   SOAP  A better choice for integration between legacy critical systems and a web web-service system  on the foundation layer  where WS-  make sense  security  policy  etc      RESTful  A better choice for integration between websites  with public API  on the TOP of layer  VIEW  ie  javascripts taking calls to URIs

User · Answer

Quick lowdown for 2012 question   Areas that REST works really well for are    Limited bandwidth and resources  Remember the return structure is really in any format  developer defined   Plus  any browser can be used because the REST approach uses the standard  GET   PUT   POST  and  DELETE  verbs  Again  remember that REST can also use the  XMLHttpRequest  object that most modern browsers support today  which adds an extra bonus of AJAX  Totally stateless operations   If an operation needs to be continued  then REST is not the best approach and SOAP may fit it better  However  if you need stateless CRUD  Create  Read  Update  and Delete  operations  then REST is it  Caching situations   If the information can be cached because of the totally stateless operation of the REST approach  this is perfect That covers a lot of solutions in the above three     So why would I even consider SOAP  Again  SOAP is fairly mature and well-defined and does come with a complete specification  The REST approach is just that  an approach and is wide open for development  so if you have the following then SOAP is a great solution    Asynchronous processing and invocation   If your application needs a guaranteed level of reliability and security then SOAP 1 2 offers additional standards to ensure this type of operation  Things like WSRM     WS-Reliable Messaging  Formal contracts   If both sides  provider and consumer  have to agree on the exchange format then SOAP 1 2 gives the rigid specifications for this type of interaction  Stateful operations  If the application needs contextual information and conversational state management then SOAP 1 2 has the additional specification in the WS  structure to support those things  Security  Transactions  Coordination  etc   Comparatively  the REST approach would make the developers build this custom plumbing    http   www infoq com articles rest-soap-when-to-use-each

User · Answer

REST is an architecture invented by Roy Fielding and described in his dissertation Architectural Styles and the Design of Network-based Software Architectures  Roy is also the main author of HTTP - the protocol that defines document transfer over the World Wide Web  HTTP is a RESTful protocol  When developers talk about  using REST Web services  it is probably more accurate to say  using HTTP    SOAP is a XML-based protocol that tunnels inside an HTTP request response  so even if you use SOAP  you are using REST too  There is some debate over whether SOAP adds any significant functionality to basic HTTP   Before authoring a Web service  I would recommend studying HTTP  Odds are your requirements can be implemented with functionality already defined in the spec  so other protocols won t be needed

User · Answer

I d recommend you go with REST first - if you re using Java look at JAX-RS and the Jersey implementation  REST is much simpler and easy to interop in many languages    As others have said in this thread  the problem with SOAP is its complexity when the other WS-  specifications come in and there are countless interop issues if you stray into the wrong parts of WSDL  XSDs  SOAP  WS-Addressing etc   The best way to judge the REST v SOAP debate is look on the internet - pretty much all the big players in the web space  google  amazon  ebay  twitter et al - tend to use and prefer RESTful APIs over the SOAP ones   The other nice approach to going with REST is that you can reuse lots of code and infratructure between a web application and a REST front end  e g  rendering HTML versus XML versus JSON of your resources is normally pretty easy with frameworks like JAX-RS and implicit views - plus its easy to work with RESTful resources using a web browser

User · Answer

I d recommend you go with REST first - if you re using Java look at JAX-RS and the Jersey implementation  REST is much simpler and easy to interop in many languages    As others have said in this thread  the problem with SOAP is its complexity when the other WS-  specifications come in and there are countless interop issues if you stray into the wrong parts of WSDL  XSDs  SOAP  WS-Addressing etc   The best way to judge the REST v SOAP debate is look on the internet - pretty much all the big players in the web space  google  amazon  ebay  twitter et al - tend to use and prefer RESTful APIs over the SOAP ones   The other nice approach to going with REST is that you can reuse lots of code and infratructure between a web application and a REST front end  e g  rendering HTML versus XML versus JSON of your resources is normally pretty easy with frameworks like JAX-RS and implicit views - plus its easy to work with RESTful resources using a web browser

User · Answer

SOAP is useful from a tooling perspective because the WSDL is so easily consumed by tools   So  you can get Web Service clients generated for you in your favorite language   REST plays well with AJAX y web pages   If you keep your requests simple  you can make service calls directly from your JavaScript  and that comes in very handy   Try to stay away from having any namespaces in your response XML  I ve seen browsers choke on those   So  xsi type is probably not going to work for you  no overly complex XML Schemas   REST tends to have better performance as well   CPU requirements of the code generating REST responses tend to be lower than what SOAP frameworks exhibit   And  if you have your XML generation ducks lined up on the server side  you can effectively stream XML out to the client   So  imagine you re reading rows of database cursor   As you read a row  you format it as an XML element  and you write that directly out to the service consumer   This way  you don t have to collect all of the database rows in memory before starting to write your XML output - you read and write at the same time   Look into novel templating engines or XSLT to get the streaming to work for REST   SOAP on the other hand tends to get generated by tool-generated services as a big blob and only then written   This is not an absolute truth  mind you  there are ways to get streaming characteristics out of SOAP  like by using attachments     My decision making process is as follows   if I want my service to be easily tooled by consumers  and the messages I write will be medium-to-small-ish  10MB or less   and I don t mind burning some extra CPU cycles on the server  I go with SOAP   If I need to serve to AJAX on web browsers  or I need the thing to stream  or my responses are gigantic  I go REST   Finally  there are lots of great standards built up around SOAP  like WS-Security and getting stateful Web Services  that you can plug in to if you re using the right tools   That kind of stuff really makes a difference  and can help you satisfy some hairy requirements

User · Answer

I built one of the first SOAP servers  including code generation and WSDL generation  from the original spec as it was being developed  when I was working at Hewlett-Packard  I do NOT recommend using SOAP for anything   The acronym  SOAP  is a lie  It is not Simple  it is not Object-oriented  it defines no Access rules  It is  arguably  a Protocol  It is Don Box s worst spec ever  and that s quite a feat  as he s the man who perpetrated  COM    There is nothing useful in SOAP that can t be done with REST for transport  and JSON  XML  or even plain text for data representation  For transport security  you can use https  For authentication  basic auth  For sessions  there s cookies  The REST version will be simpler  clearer  run faster  and use less bandwidth   XML-RPC clearly defines the request  response  and error protocols  and there are good libraries for most languages  However  XML is heavier than you need for many tasks

User · Answer

I m sure Don Box created SOAP as a joke -  look you can call RPC methods over the web  and today groans when he realises what a bloated nightmare of web standards it has become  -   REST is good  simple  implemented everywhere  so more a  standard  than the standards  fast and easy  Use REST

User · Answer

I m sure Don Box created SOAP as a joke -  look you can call RPC methods over the web  and today groans when he realises what a bloated nightmare of web standards it has become  -   REST is good  simple  implemented everywhere  so more a  standard  than the standards  fast and easy  Use REST

User · Answer

My general rule is that if you want a browser web client to directly connect to a service then you should probably use REST  If you want to pass structured data between back-end services then use SOAP   SOAP can be a real pain to set up sometimes and is often overkill for simple web client and server data exchanges  Unfortunately  most simple programming examples I ve seen  and learned from  somewhat reenforce this perception    That said  SOAP really shines when you start combining multiple SOAP services together as part of a larger process driven by a data workflow  think enterprise software   This is something that many of the SOAP programming examples fail to convey because a simple SOAP operation to do something  like fetch the price of a stock  is generally overcomplicated for what it does by itself unless it is presented in the context of providing a machine readable API detailing specific functions with set data formats for inputs and outputs that is  in turn  scripted by a larger process   This is sad  in a way  as it really gives SOAP a bad reputation because it is difficult to show the advantages of SOAP without presenting it in the full context of how the final product is used

User · Answer

i create a benchmark for find which of them are faster  i see this result   for 1000 requests     REST took 3 second SOAP took 7 second   for 10 000 requests     REST took 33 second SOAP took 69 second   for 1 000 000 requests     REST took 62 second SOAP took 114 second

User · Answer

It s nuanced   If you need to have other systems interface with your services  than a lot of clients will be happier with SOAP  due to the layers of  verification  you have with the contracts  WSDL  and the SOAP standard   For day-to-day systems calling into systems  I think that SOAP is a lot of unnecessary overhead when a simple HTML call will do

User · Answer

I am looking at the same  and i think   they are  different tools for different problems   Simple Object Access Protocol  SOAP  standard an XML language defining a message architecture and message formats  is used by Web services it contain a description of the operations  WSDL is an XML-based language for describing Web services and how to access them  will run on SMTP HTTP FTP etc  Requires middleware support  well defined mechanisam to define services like WSDL XSD  WS-Policy SOAP will return XML based data SOAP provide standards for security and reliability  Representational State Transfer  RESTful  web services  they are second generation Web Services  RESTful web services  communicate via HTTP than SOAP-based services and do not require XML messages or WSDL service-API definitions  for REST no middleware is required only HTTP support is needed WADL Standard  REST can return XML  plain text  JSON  HTML etc  It is easier for many types of clients to consume RESTful web services while enabling the server side to evolve and scale  Clients can choose to consume some or all aspects of the service and mash it up with other web-based services    REST uses standard HTTP so it is simplerto creating clients  developing APIs REST permits many different data formats  like XML  plain text  JSON  HTML  where as SOAP only permits XML  REST has better performance and scalability   Rest and can be cached and SOAP can t Built-in error handling where SOAP has No error handling REST is particularly useful PDA and other mobile devices    REST is services are easy to integrate with existing websites   SOAP has  set of protocols  which provide standards for security and reliability  among other things  and interoperate with other WS conforming clients and servers  SOAP Web services  such as JAX-WS  are useful in handling asynchronous processing and invocation   For Complex API s SOAP will be  more usefull

User · Answer

REST is a fundamentally different paradigm from SOAP. A good read on REST can be found here: How I explained REST to my wife.

If you don't have time to read it, here's the short version: REST is a bit of a paradigm shift by focusing on "nouns", and restraining the number of "verbs" you can apply to those nouns. The only allowed verbs are "get", "put", "post" and "delete". This differs from SOAP where many different verbs can be applied to many different nouns (i.e. many different functions).

For REST, the four verbs map to the corresponding HTTP requests, while the nouns are identified by URLs. This makes state management much more transparent than in SOAP, where its often unclear what state is on the server and what is on the client.

In practice though most of this falls away, and REST usually just refers to simple HTTP requests that return results in JSON, while SOAP is a more complex API that communicates by passing XML around. Both have their advantages and disadvantages, but I've found that in my experience REST is usually the better choice because you rarely if ever need the full functionality you get from SOAP.

User · Answer

Listen to this podcast to find out  If you want to know the answer without listening  then OK  its REST   But I really do recommend listening

User · Answer

REST is a fundamentally different paradigm from SOAP. A good read on REST can be found here: How I explained REST to my wife.

If you don't have time to read it, here's the short version: REST is a bit of a paradigm shift by focusing on "nouns", and restraining the number of "verbs" you can apply to those nouns. The only allowed verbs are "get", "put", "post" and "delete". This differs from SOAP where many different verbs can be applied to many different nouns (i.e. many different functions).

For REST, the four verbs map to the corresponding HTTP requests, while the nouns are identified by URLs. This makes state management much more transparent than in SOAP, where its often unclear what state is on the server and what is on the client.

In practice though most of this falls away, and REST usually just refers to simple HTTP requests that return results in JSON, while SOAP is a more complex API that communicates by passing XML around. Both have their advantages and disadvantages, but I've found that in my experience REST is usually the better choice because you rarely if ever need the full functionality you get from SOAP.

User · Answer

Listen to this podcast to find out  If you want to know the answer without listening  then OK  its REST   But I really do recommend listening

User · Answer

If you are looking for interoperability between different systems and languages  I would definately go for REST   I ve had a lot of problems trying to get SOAP working between  NET and Java  for example

User · Answer

I am looking at the same  and i think   they are  different tools for different problems   Simple Object Access Protocol  SOAP  standard an XML language defining a message architecture and message formats  is used by Web services it contain a description of the operations  WSDL is an XML-based language for describing Web services and how to access them  will run on SMTP HTTP FTP etc  Requires middleware support  well defined mechanisam to define services like WSDL XSD  WS-Policy SOAP will return XML based data SOAP provide standards for security and reliability  Representational State Transfer  RESTful  web services  they are second generation Web Services  RESTful web services  communicate via HTTP than SOAP-based services and do not require XML messages or WSDL service-API definitions  for REST no middleware is required only HTTP support is needed WADL Standard  REST can return XML  plain text  JSON  HTML etc  It is easier for many types of clients to consume RESTful web services while enabling the server side to evolve and scale  Clients can choose to consume some or all aspects of the service and mash it up with other web-based services    REST uses standard HTTP so it is simplerto creating clients  developing APIs REST permits many different data formats  like XML  plain text  JSON  HTML  where as SOAP only permits XML  REST has better performance and scalability   Rest and can be cached and SOAP can t Built-in error handling where SOAP has No error handling REST is particularly useful PDA and other mobile devices    REST is services are easy to integrate with existing websites   SOAP has  set of protocols  which provide standards for security and reliability  among other things  and interoperate with other WS conforming clients and servers  SOAP Web services  such as JAX-WS  are useful in handling asynchronous processing and invocation   For Complex API s SOAP will be  more usefull

User · Answer

One quick point - transmission protocol and orchestration   I use SOAP over TCP for speed  reliability and security reasons  including orchestrated machine to machine services  ESB  and to external services   Change the service definition  the orchestration raises an error from the WSDL change and its immediately obvious and can be rebuilt deployed   Not sure you can do the same with REST - I await being corrected or course  With REST  change the service definition - nothing knows about it until it returns 400  or whatever

User · Answer

It s a good question    I don t want to lead you astray  so I m open to other people s answers as much as you are   For me  it really comes down to cost of overhead and what the use of the API is   I prefer consuming web services when creating client software  however I don t like the weight of SOAP   REST  I believe  is lighter weight but I don t enjoy working with it from a client perspective nearly as much   I m curious as to what others think

User · Answer

SOAP embodies a service-oriented approach to Web services     one in which methods  or verbs  are the primary way you interact with the service  REST takes a resource-oriented approach in which the object  or the noun  takes center stage

User · Answer

SOAP is useful from a tooling perspective because the WSDL is so easily consumed by tools   So  you can get Web Service clients generated for you in your favorite language   REST plays well with AJAX y web pages   If you keep your requests simple  you can make service calls directly from your JavaScript  and that comes in very handy   Try to stay away from having any namespaces in your response XML  I ve seen browsers choke on those   So  xsi type is probably not going to work for you  no overly complex XML Schemas   REST tends to have better performance as well   CPU requirements of the code generating REST responses tend to be lower than what SOAP frameworks exhibit   And  if you have your XML generation ducks lined up on the server side  you can effectively stream XML out to the client   So  imagine you re reading rows of database cursor   As you read a row  you format it as an XML element  and you write that directly out to the service consumer   This way  you don t have to collect all of the database rows in memory before starting to write your XML output - you read and write at the same time   Look into novel templating engines or XSLT to get the streaming to work for REST   SOAP on the other hand tends to get generated by tool-generated services as a big blob and only then written   This is not an absolute truth  mind you  there are ways to get streaming characteristics out of SOAP  like by using attachments     My decision making process is as follows   if I want my service to be easily tooled by consumers  and the messages I write will be medium-to-small-ish  10MB or less   and I don t mind burning some extra CPU cycles on the server  I go with SOAP   If I need to serve to AJAX on web browsers  or I need the thing to stream  or my responses are gigantic  I go REST   Finally  there are lots of great standards built up around SOAP  like WS-Security and getting stateful Web Services  that you can plug in to if you re using the right tools   That kind of stuff really makes a difference  and can help you satisfy some hairy requirements

User · Answer

SOAP currently has the advantage of better tools where they will generate a lot of the boilerplate code for both the service layer as well as generating clients from any given WSDL    REST is simpler  can be easier to maintain as a result  lies at the heart of Web architecture  allows for better protocol visibility  and has been proven to scale at the size of the WWW itself  Some frameworks out there help you build REST services  like Ruby on Rails  and some even help you with writing clients  like ADO NET Data Services  But for the most part  tool support is lacking

User · Answer

If you are looking for interoperability between different systems and languages  I would definately go for REST   I ve had a lot of problems trying to get SOAP working between  NET and Java  for example

User · Answer

I built one of the first SOAP servers  including code generation and WSDL generation  from the original spec as it was being developed  when I was working at Hewlett-Packard  I do NOT recommend using SOAP for anything   The acronym  SOAP  is a lie  It is not Simple  it is not Object-oriented  it defines no Access rules  It is  arguably  a Protocol  It is Don Box s worst spec ever  and that s quite a feat  as he s the man who perpetrated  COM    There is nothing useful in SOAP that can t be done with REST for transport  and JSON  XML  or even plain text for data representation  For transport security  you can use https  For authentication  basic auth  For sessions  there s cookies  The REST version will be simpler  clearer  run faster  and use less bandwidth   XML-RPC clearly defines the request  response  and error protocols  and there are good libraries for most languages  However  XML is heavier than you need for many tasks

User · Answer

It s a good question    I don t want to lead you astray  so I m open to other people s answers as much as you are   For me  it really comes down to cost of overhead and what the use of the API is   I prefer consuming web services when creating client software  however I don t like the weight of SOAP   REST  I believe  is lighter weight but I don t enjoy working with it from a client perspective nearly as much   I m curious as to what others think

User · Answer

Most of the applications I write are server-side C  or Java  or desktop applications in WinForms or WPF   These applications tend to need a richer service API than REST can provide   Plus  I don t want to spend any more than a couple minutes creating my web service client   The WSDL processing client generation tools allow me to implement my client and move on to adding business value   Now  if I were writing a web service explicitly for some javascript ajax calls  it d probably be in REST  just for the sake knowing the client technology and leveraging JSON   In my opinion  web service APIs used from javascript probably shouldn t be very complex  as that type of complexity seems to be better handled server-side   With that said  there some SOAP clients for javascript  I know jQuery has one   Thus  SOAP can be leveraged from javascript  just not as nicely as a REST service returning JSON strings  So if I had a web service that I wanted to be complex enough that it was flexible for an arbitrary number of client technologies and uses  I d go with SOAP

User · Answer

One thing that hasn t been mentioned is that a SOAP envelope can contain headers as well as body parts  This lets you use the full expressiveness of XML to send and receive out of band information  REST  as far as I know  limits you to HTTP Headers and result codes    otoh  can you use cookies with a REST service to send  header -type out of band data

User · Answer

Answering the 2012 refreshed  by the second bounty  question  and reviewing the today s results  other answers    SOAP  pros and cons About SOAP 1 2  advantages and drawbacks when comparing with  quot REST quot     Well  since 2007 you can describe REST Web services with WSDL  and using SOAP protocol    That is  if you work a little harder  all W3C standards of the web services protocol stack can be REST  It is a good starting point  because we can imagine a scenario in which all the philosophical and methodological discussions are temporarily avoided  We can compare technically  quot SOAP-REST quot  with  quot NON-SOAP-REST quot  in similar services   SOAP-REST    quot REST-SOAP quot    as showed by L Mandel  WSDL2 can describe a REST webservice  and  if we suppose that exemplified XML can be enveloped in SOAP  all the implementation will be  quot SOAP-REST quot    NON-SOAP-REST  any REST web service that can not be SOAP    That is   quot 90  quot  of the well-knowed REST examples  Some not use XML  ex  typical AJAX RESTs use JSON instead   some use another XML strucutures  without the SOAP headers or rules  PS  to avoid informality  we can suppose REST level 2 in the comparisons    Of course  to compare more conceptually  compare  quot NON-REST-SOAP quot  with  quot NON-SOAP-REST quot   as different modeling approaches  So  completing this taxonomy of web services   NON-REST-SOAP  any SOAP web service that can not be REST    That is   quot 90  quot  of the well-knowed SOAP examples   NON-REST-NEITHER-SOAP  yes  the universe of  quot web services modeling quot  comprises other things  ex  XML-RPC     SOAP in the REST condictions Comparing comparable things  SOAP-REST with NON-SOAP-REST  PROS Explaining some terms   Contractual stability  for all kinds of contracts  as  quot written agreements quot     By the use of standars  all levels of the W3C stack  are mutually compliant   REST  by other hand  is not a W3C or ISO standard  and have no normatized details about service s peripherals  So  as I   DaveWoldrich 20 votes    cynicalman 5    Exitos 0  said before  in a context where are NEED FOR STANDARDS  you need SOAP   By the use of best practices  the  quot verbose aspect quot  of the W3C stack implementations  translates relevant human legal juridic agreements     Robustness  the safety of SOAP structure and headers  With metada communication  with the full expressiveness of XML  and verification you have an  quot insurance policy quot  against any changes or noise   SOAP have  quot transactional reliability       deal with communication failures  SOAP has more controls around retry logic and thus can provide more end-to-end reliability and service guarantees quot   E  Terman    Sorting pros by popularity   Better tools   70 votes   SOAP currently has the advantage of better tools  since 2007 and still 2012  because it is a well-defined and widely accepted standard   See  MarkCidade 27 votes    DaveWoldrich 20    JoshM 13    TravisHeseman 9    Standars compliance  25 votes   as I   DaveWoldrich 20 votes    cynicalman 5    Exitos 0  said before  in a context where are NEED FOR STANDARDS  you need SOAP   Robustness  insurance of SOAP headers   JohnSaunders  8 votes     CONS  SOAP strucuture is more complex  more than 300 votes   all answers here  and sources about  quot SOAP vs REST quot   manifest some degree of dislike with SOAP s redundancy and complexity  This is a natural consequence of the requirements for formal verification  see below   and for robustness  see above    quot REST NON-SOAP quot   and XML-RPC  the SOAP originator  can be more simple and informal   The  quot only XML quot  restriction is a performance obstacle when using tiny services   50 votes   see json org xml and this question  or this other one   This point is showed by  toluju 41   and others   PS  as JSON is not a IETF standard  but we can consider a de facto standard for web software community     Modeling services with SOAP Now  we can add SOAP-NON-REST with NON-SOAP-REST comparisons  and explain when is better to use SOAP   Need for standards and stable contracts  see  quot PROS quot  section   PS  see a typical  quot B2B need for standards quot  described by  saille   Need for tools  see  quot PROS quot  section   PS  standards  and the existence of formal verifications  see bellow   are important issues for the tools automation   Parallel heavy processing  see  quot Context Foundations quot  section below   with bigger and or slower processes  no matter with a bit more complexity of SOAP  reliability and stability are the best investments   Need more security  when more than HTTPS is required  and you really need additional features for protection  SOAP is a better choice  see  Bell  32 votes    quot Sending the message along a path more complicated than request response or over a transport that does not involve HTTP quot   S  Seely  XML is a core issue  offering standards for XML Encryption  XML Signature  and XML Canonicalization  and  only with SOAP you can to embed these mechanisms into a message by a well-accepted standard as WS-Security   Need more flexibility  less restrictions   SOAP not need exact correspondence with an URI  not nedd restrict to HTTP  not need to restrict to 4 verbs  As  TravisHeseman  9 votes  says  if you wanted something  quot flexible for an arbitrary number of client technologies and uses quot   use SOAP PS  remember that XML is more universal expressive than JSON  et al    Need for formal verifications  important to understand that W3C stack uses formal methods  and REST is more informal   Your WSDL  a formal language  service description is a formal specification  of your web services interfaces  and SOAP is a robust protocol that accept all possible WSDL prescriptions    CONTEXT Historical To assess trends is necessary historical perspective  For this subject  a 10 or 15 years perspective    Before the W3C standardization  there are some anarchy  Was difficult to implement interoperable services with different frameworks  and more difficult  costly  and time consuming to implement something interoperable between companys  The W3C stack standards has been a light  a north for interoperation of sets of complex web services  For day-by-day tasks  like to implement AJAX  SOAP is heavy    So  the need for simple approaches need to elect a new theory-framework    And big  quot Web software players quot   as Google  Amazon  Yahoo  et al   elected the best alternative  that is the REST approach  Was in this context that REST concept arrived as a  quot competing framework quot   and  today  2012 s   this alternative  is  a de facto standard for programmers  Foundations In a context of Parallel Computing the web services provides parallel subtasks  and protocols  like SOAP  ensures good synchronization and communication  Not  quot any task quot   web services can be classified as coarse-grained and embarrassing parallelism  As the task gets bigger  it becomes less significant  quot complexity debate quot   and becomes more relevant the robustness of the communication and the solidity of the contracts

User · Answer

SOAP currently has the advantage of better tools where they will generate a lot of the boilerplate code for both the service layer as well as generating clients from any given WSDL    REST is simpler  can be easier to maintain as a result  lies at the heart of Web architecture  allows for better protocol visibility  and has been proven to scale at the size of the WWW itself  Some frameworks out there help you build REST services  like Ruby on Rails  and some even help you with writing clients  like ADO NET Data Services  But for the most part  tool support is lacking

User · Answer

If you are looking for interoperability between different systems and languages  I would definately go for REST   I ve had a lot of problems trying to get SOAP working between  NET and Java  for example

User · Answer

I d recommend you go with REST first - if you re using Java look at JAX-RS and the Jersey implementation  REST is much simpler and easy to interop in many languages    As others have said in this thread  the problem with SOAP is its complexity when the other WS-  specifications come in and there are countless interop issues if you stray into the wrong parts of WSDL  XSDs  SOAP  WS-Addressing etc   The best way to judge the REST v SOAP debate is look on the internet - pretty much all the big players in the web space  google  amazon  ebay  twitter et al - tend to use and prefer RESTful APIs over the SOAP ones   The other nice approach to going with REST is that you can reuse lots of code and infratructure between a web application and a REST front end  e g  rendering HTML versus XML versus JSON of your resources is normally pretty easy with frameworks like JAX-RS and implicit views - plus its easy to work with RESTful resources using a web browser

User · Answer

REST is an architecture  SOAP is a protocol   That s the first problem   You can send SOAP envelopes in a REST application   SOAP itself is actually pretty basic and simple  it s the WSS-  standards on top of it that make it very complex   If your consumers are other applications and other servers  there s a lot of support for the SOAP protocol today  and the basics of moving data is essentially a mouse-click in modern IDEs   If your consumers are more likely to be RIAs or Ajax clients  you will probably want something simpler than SOAP  and more native to the client  notably JSON    JSON packets sent over HTTP is not necessarily a REST architecture  it s just messages to URLs  All perfectly workable  but there are key components to the REST idiom  It is easy to confuse the two however  But just because you re talking HTTP requests does not necessarily mean you have a REST architecture  You can have a REST application with no HTTP at all  mind  this is rare    So  if you have servers and consumers that are  comfortable  with SOAP  SOAP and WSS stack can serve you well  If you re doing more ad hoc things and want to better interface with web browsers  then some lighter protocol over HTTP can work well also

User · Answer

If you are looking for interoperability between different systems and languages  I would definately go for REST   I ve had a lot of problems trying to get SOAP working between  NET and Java  for example

User · Answer

I know this is an old question but I have to post my answer - maybe someone will find it useful  I can t believe how many people are recommending REST over SOAP  I can only assume these people are not developers or have never actually implemented a REST service of any reasonable size  Implementing a REST service takes a LOT longer than implementing a SOAP service  And in the end it comes out a lot messier  too  Here are the reasons I would choose SOAP 99  of the time   1  Implementing a REST service takes infinitely longer than implementing a SOAP service  Tools exist for all modern languages frameworks platforms to read in a WSDL and output proxy classes and clients  Implementing a REST service is done by hand and - get this - by reading documentation  Furthermore  while implementing these two services  you have to make  guesses  as to what will come back across the pipe as there is no real schema or reference document   2  Why write a REST service that returns XML anyway  The only difference is that with REST you don t know the types each element attribute represents - you are on your own to implement it and hope that one day a string doesn t come across in a field you thought was always an int  SOAP defines the data structure using the WSDL so this is a no-brainer   3  I ve heard the complaint that with SOAP you have the  overhead  of the SOAP Envelope  In this day and age  do we really need to worry about a handful of bytes   4  I ve heard the argument that with REST you can just pop the URL into the browser and see the data  Sure  if your REST service is using simple or no authentication  The Netflix service  for instance  uses OAuth which requires you to sign things and encode things before you can even submit your request   5  Why do we need a  readable  URL for each resource  If we were using a tool to implement the service  do we really care about the actual URL   Need I go on

User · Answer

Answering the 2012 refreshed  by the second bounty  question  and reviewing the today s results  other answers    SOAP  pros and cons About SOAP 1 2  advantages and drawbacks when comparing with  quot REST quot     Well  since 2007 you can describe REST Web services with WSDL  and using SOAP protocol    That is  if you work a little harder  all W3C standards of the web services protocol stack can be REST  It is a good starting point  because we can imagine a scenario in which all the philosophical and methodological discussions are temporarily avoided  We can compare technically  quot SOAP-REST quot  with  quot NON-SOAP-REST quot  in similar services   SOAP-REST    quot REST-SOAP quot    as showed by L Mandel  WSDL2 can describe a REST webservice  and  if we suppose that exemplified XML can be enveloped in SOAP  all the implementation will be  quot SOAP-REST quot    NON-SOAP-REST  any REST web service that can not be SOAP    That is   quot 90  quot  of the well-knowed REST examples  Some not use XML  ex  typical AJAX RESTs use JSON instead   some use another XML strucutures  without the SOAP headers or rules  PS  to avoid informality  we can suppose REST level 2 in the comparisons    Of course  to compare more conceptually  compare  quot NON-REST-SOAP quot  with  quot NON-SOAP-REST quot   as different modeling approaches  So  completing this taxonomy of web services   NON-REST-SOAP  any SOAP web service that can not be REST    That is   quot 90  quot  of the well-knowed SOAP examples   NON-REST-NEITHER-SOAP  yes  the universe of  quot web services modeling quot  comprises other things  ex  XML-RPC     SOAP in the REST condictions Comparing comparable things  SOAP-REST with NON-SOAP-REST  PROS Explaining some terms   Contractual stability  for all kinds of contracts  as  quot written agreements quot     By the use of standars  all levels of the W3C stack  are mutually compliant   REST  by other hand  is not a W3C or ISO standard  and have no normatized details about service s peripherals  So  as I   DaveWoldrich 20 votes    cynicalman 5    Exitos 0  said before  in a context where are NEED FOR STANDARDS  you need SOAP   By the use of best practices  the  quot verbose aspect quot  of the W3C stack implementations  translates relevant human legal juridic agreements     Robustness  the safety of SOAP structure and headers  With metada communication  with the full expressiveness of XML  and verification you have an  quot insurance policy quot  against any changes or noise   SOAP have  quot transactional reliability       deal with communication failures  SOAP has more controls around retry logic and thus can provide more end-to-end reliability and service guarantees quot   E  Terman    Sorting pros by popularity   Better tools   70 votes   SOAP currently has the advantage of better tools  since 2007 and still 2012  because it is a well-defined and widely accepted standard   See  MarkCidade 27 votes    DaveWoldrich 20    JoshM 13    TravisHeseman 9    Standars compliance  25 votes   as I   DaveWoldrich 20 votes    cynicalman 5    Exitos 0  said before  in a context where are NEED FOR STANDARDS  you need SOAP   Robustness  insurance of SOAP headers   JohnSaunders  8 votes     CONS  SOAP strucuture is more complex  more than 300 votes   all answers here  and sources about  quot SOAP vs REST quot   manifest some degree of dislike with SOAP s redundancy and complexity  This is a natural consequence of the requirements for formal verification  see below   and for robustness  see above    quot REST NON-SOAP quot   and XML-RPC  the SOAP originator  can be more simple and informal   The  quot only XML quot  restriction is a performance obstacle when using tiny services   50 votes   see json org xml and this question  or this other one   This point is showed by  toluju 41   and others   PS  as JSON is not a IETF standard  but we can consider a de facto standard for web software community     Modeling services with SOAP Now  we can add SOAP-NON-REST with NON-SOAP-REST comparisons  and explain when is better to use SOAP   Need for standards and stable contracts  see  quot PROS quot  section   PS  see a typical  quot B2B need for standards quot  described by  saille   Need for tools  see  quot PROS quot  section   PS  standards  and the existence of formal verifications  see bellow   are important issues for the tools automation   Parallel heavy processing  see  quot Context Foundations quot  section below   with bigger and or slower processes  no matter with a bit more complexity of SOAP  reliability and stability are the best investments   Need more security  when more than HTTPS is required  and you really need additional features for protection  SOAP is a better choice  see  Bell  32 votes    quot Sending the message along a path more complicated than request response or over a transport that does not involve HTTP quot   S  Seely  XML is a core issue  offering standards for XML Encryption  XML Signature  and XML Canonicalization  and  only with SOAP you can to embed these mechanisms into a message by a well-accepted standard as WS-Security   Need more flexibility  less restrictions   SOAP not need exact correspondence with an URI  not nedd restrict to HTTP  not need to restrict to 4 verbs  As  TravisHeseman  9 votes  says  if you wanted something  quot flexible for an arbitrary number of client technologies and uses quot   use SOAP PS  remember that XML is more universal expressive than JSON  et al    Need for formal verifications  important to understand that W3C stack uses formal methods  and REST is more informal   Your WSDL  a formal language  service description is a formal specification  of your web services interfaces  and SOAP is a robust protocol that accept all possible WSDL prescriptions    CONTEXT Historical To assess trends is necessary historical perspective  For this subject  a 10 or 15 years perspective    Before the W3C standardization  there are some anarchy  Was difficult to implement interoperable services with different frameworks  and more difficult  costly  and time consuming to implement something interoperable between companys  The W3C stack standards has been a light  a north for interoperation of sets of complex web services  For day-by-day tasks  like to implement AJAX  SOAP is heavy    So  the need for simple approaches need to elect a new theory-framework    And big  quot Web software players quot   as Google  Amazon  Yahoo  et al   elected the best alternative  that is the REST approach  Was in this context that REST concept arrived as a  quot competing framework quot   and  today  2012 s   this alternative  is  a de facto standard for programmers  Foundations In a context of Parallel Computing the web services provides parallel subtasks  and protocols  like SOAP  ensures good synchronization and communication  Not  quot any task quot   web services can be classified as coarse-grained and embarrassing parallelism  As the task gets bigger  it becomes less significant  quot complexity debate quot   and becomes more relevant the robustness of the communication and the solidity of the contracts

User · Answer

I m sure Don Box created SOAP as a joke -  look you can call RPC methods over the web  and today groans when he realises what a bloated nightmare of web standards it has become  -   REST is good  simple  implemented everywhere  so more a  standard  than the standards  fast and easy  Use REST

User · Answer

REST is an architecture  SOAP is a protocol   That s the first problem   You can send SOAP envelopes in a REST application   SOAP itself is actually pretty basic and simple  it s the WSS-  standards on top of it that make it very complex   If your consumers are other applications and other servers  there s a lot of support for the SOAP protocol today  and the basics of moving data is essentially a mouse-click in modern IDEs   If your consumers are more likely to be RIAs or Ajax clients  you will probably want something simpler than SOAP  and more native to the client  notably JSON    JSON packets sent over HTTP is not necessarily a REST architecture  it s just messages to URLs  All perfectly workable  but there are key components to the REST idiom  It is easy to confuse the two however  But just because you re talking HTTP requests does not necessarily mean you have a REST architecture  You can have a REST application with no HTTP at all  mind  this is rare    So  if you have servers and consumers that are  comfortable  with SOAP  SOAP and WSS stack can serve you well  If you re doing more ad hoc things and want to better interface with web browsers  then some lighter protocol over HTTP can work well also

User · Answer

Don t overlook XML-RPC   If you re just after a lightweight solution then there s a great deal to be said for a protocol that can be defined in a couple of pages of text and implemented in a minimal amount of code   XML-RPC has been around for years but went out of fashion for a while - but the minimalist appeal seems to be giving it something of a revival of late

User · Answer

SOAP currently has the advantage of better tools where they will generate a lot of the boilerplate code for both the service layer as well as generating clients from any given WSDL    REST is simpler  can be easier to maintain as a result  lies at the heart of Web architecture  allows for better protocol visibility  and has been proven to scale at the size of the WWW itself  Some frameworks out there help you build REST services  like Ruby on Rails  and some even help you with writing clients  like ADO NET Data Services  But for the most part  tool support is lacking

User · Answer

In sense with  PHP-universe  PHP support for any advanced SOAP sucks big time  You will end up using something like http   wso2 com products web-services-framework php  as soon as you cross the basic needs  even to enable WS-Security or WS-RM no inbuilt support   SOAP envelope creation I feel is lot messy in PHP  the way it creates namespaces  xsd nil  xsd anytype and old styled soap Services which use SOAP Encoding  God knows how s that different  with in SOAP messages    Avoid all this mess by sticking to REST  REST is nothing really big we have been using it since the start of WWW  We realized only when this http   www ics uci edu  fielding pubs dissertation top htm paper came out it shows how can we use HTTP capabilities to implement RESTFul Services  HTTP is inherently REST  that doesn t mean just using HTTP makes your services RESTFul    SOAP neglects the core capabilities of HTTP and considers HTTP just as an transport protocol  hence it is transport protocol independent in theory  in practical it s not the case have you heard of SOAP Action header  if not google it now     With JSON adaption increasing and HTML5 with javascript maturing REST with JSON has become the most common way of dealing with services  JSON Schema has also been defined can be used for enterprise level solutions  still in early stages  along with WADL if needed    PHP support for REST and JSON is definitely better than existing inbuilt SOAP support it has    Adding few more BUZZ words here SOA  WOA  ROA   http   blog dhananjaynene com 2009 06 rest-soa-woa-or-roa   http   www scribd com doc 15657444 REST-White-Paper  by the way I do love SOAP especially for the WS-Security spec  this is one good spec and if someone thinking in Enterprise JSON adaption definetly need to come with some thing similar for JSON  like field level encryption etc

User · Answer

My general rule is that if you want a browser web client to directly connect to a service then you should probably use REST  If you want to pass structured data between back-end services then use SOAP   SOAP can be a real pain to set up sometimes and is often overkill for simple web client and server data exchanges  Unfortunately  most simple programming examples I ve seen  and learned from  somewhat reenforce this perception    That said  SOAP really shines when you start combining multiple SOAP services together as part of a larger process driven by a data workflow  think enterprise software   This is something that many of the SOAP programming examples fail to convey because a simple SOAP operation to do something  like fetch the price of a stock  is generally overcomplicated for what it does by itself unless it is presented in the context of providing a machine readable API detailing specific functions with set data formats for inputs and outputs that is  in turn  scripted by a larger process   This is sad  in a way  as it really gives SOAP a bad reputation because it is difficult to show the advantages of SOAP without presenting it in the full context of how the final product is used

User · Answer

One quick point - transmission protocol and orchestration   I use SOAP over TCP for speed  reliability and security reasons  including orchestrated machine to machine services  ESB  and to external services   Change the service definition  the orchestration raises an error from the WSDL change and its immediately obvious and can be rebuilt deployed   Not sure you can do the same with REST - I await being corrected or course  With REST  change the service definition - nothing knows about it until it returns 400  or whatever

[xml] SOAP or REST for Web Services?

Examples related to xml

Examples related to web-services

Examples related to rest

Examples related to soap