SOAP or REST for Web Services? [closed]

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.

Pharyngo

In today's world consider JSON based REST process – Chinch

A related but not duplicated thread: #34625313 – Psephology

Duplicate of -- https://mcmap.net/q/45351/-soap-vs-rest-differences – Teetotalism

possible duplicate - https://mcmap.net/q/45351/-soap-vs-rest-differences – Lisa

Answer 1

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.

Bracy

You neglected to mention that writing a service-wrapper for a REST web service will take 100000x longer than instantly generating classes from a SOAP web service WSDL. IMO REST is good for getting a blob of data that you don't have to work with. But if you want to get an object, SOAP is way quicker and easier to implement. See my post here for more info: #3286204 – Hydrography

If you intend to generate a wrapper, consider using a JSON decoder instead. Let SOAP rest in peace. – Liquidate

It is not object oriented?. Say what?. object->xml serialize->SOAP. – Robbierobbin

@JoshM: You're missing the point. SOAP was designed to give access to Objects as in Object Oriented Programming Objects; i.e., data plus methods. It's a terrible idea, because the set of operations that can be performed on an object locally and remotely MUST be very different; pretending latency doesn't exist when dealing with remote invocation is insane. Let it die. – Jamey

@Paul: Are you trying to say REST doesn't suffer from latency-related issues? I don't "get" your argument. – Hydrography

It is disappointing to see this answer get so many upvotes and a bounty. It is not a helpful answer. "There is nothing useful in SOAP that can't be done with REST..". So this guy has examined every possible problem someone might have to solve and can safely say that your web service should not use SOAP (WS-* seems to be implied here)? Yeah right. I am tired of hearing strong cries of REST > WS-* or SOAP.. it is barely comparable. – Oates

Readers should note that the experience that the OP had writing a server for the first version of SOAP has little bearing on modern versions of SOAP and its related protocols. – Ecumenicist

@Bracy how do you handle message level security and Reliable messaging in the rest – Teyde

SOAP hatting shows friendliness with Don Box. – Thunderhead

One point where REST is noticeably lacking is verb usage appropriate for searching. GET seems to fit the bill most closely, however, if you want to use a complex query (eg ElasticSearch allows very complex json objects), there's not good way to send the request. Most proxies have url length limits and/or don't support GET bodies... – Marabelle

I built one of the first SOAP web services (in 2002; Google search API). Just confirming what mdhughes says, SOAP was not a good technology. Fortunately it's past tense now and no one seriously considers using it outside of weird enterprise contexts. – Crutcher

@JohnSaunders : Sadly, the "bandwagon effect" hides the fact! – Denn

@Marabelle thats a good point, did you ever find a decent solution ? – Violet

@Violet Not really. We've ended up allowing the use of POST where we should use GET if the body may be large. Since searching is about the only scenario we've bumped into that requires a large body on GET, we don't have to handle a "real" POST at that uri. It's a hack but a manageable one. That's not to say it doesn't make me feel a little grubby... – Marabelle

@Marabelle the only other option we could think of was to include a json object as a query param. But hey mailchimp (for example) and others I am sure,only use POST requests for every single part of their api. Grubbiness ftw! – Violet

However it seems from all the answers and comments is that SOAP is great because of the auto-gen tooling. It seems programmers are only interested in a technology if it is easy for them to use, even if its a really bad technology. – Reaction

COM is a vivid example that how a single man can jeopardize the whole world. – Psephology

If you take the time to document or even do a spec-first approach to your API with Swagger, RAML or Blueprint you could just generate your objects from those docs. Prefering SOAP over REST just for the tooling it's not a valid point. – Undulatory

No thing is Entirely good or Bad There is no silver Bullet - neither is SOAP nor is REST a Silver Bullet https://mcmap.net/q/36208/-s3-rest-api-and-post-method – Catechu

Answer 2

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.

Knish

In this case, I think we are talking about two architectures over a protocol. REST is truly an architecture whereas SOAP tries to define a new protocol on the existing protocol, on top of which you must apply a RPC architecture. Silly-OAP. – Aronoff

This is clearly a much better answer than the rant that appears on this page – Spatz

Answer 3

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.

Blondellblondelle

The only allowed verbs are "get", "put", and "delete"? What about POST and OPTIONS? – Ketcham

Sorry, I forgot to mention POST. OPTIONS (and HEAD) is not considered part of the REST specification, however. – Blondellblondelle

@Blondellblondelle I wasn't aware that REST had a specification. It is an architectural style and although it might be true that OPTIONS is rarely used I don't think you can say the same about HEAD. – Pickaback

HEAD, OPTIONS, and TRACE are all methods that inquire about server meta-information rather than about the content at the URL itself. As such they are of marginal use for REST-style applications. I stand corrected in as far a specification. The main specification of significance to REST is the HTTP spec itself. – Blondellblondelle

And HTTP uses POST, OPTIONS and HEAD which are very much part of REST. – Luminary

Rest is defined in a thesis : ics.uci.edu/~fielding/pubs/dissertation/top.htm So what it is, what can be done or not is more defined that one could think. REST is not JSON over HTTP. This is what most people just need through. – Alsatian

HEAD is totally valuable for REST -- when two requests makes more sense than one (== heavy payloads & caching). But of course it's not a verb, and REST's pretensions usually fall apart in practice, the practice being stateless requests, descriptive URLs, structured responses, and use of HTTP headers for things like caching and authentication. – Blasphemy

As a note, "Rest usually ... refers to ... requests that result in JSON" - is not correct. The media-type returned is not restricted or defaulted to any format. Indeed, many REST services return application/xml, video or other media-types. In my experience, for example in corporations, REST based web-services return XML in favor of JSON. In any case, it is up to the service what is returned and the client can participate in this content-type negotiation via the HTTP "Accept" header. – Clergy

Although it is true that the media-type returned can be XML/JSON, recent trends show the adoption of JSON over XML. google.com/trends/… – Mcgill

REST still uses HTTP -- the "nouns" and "verbs" are not at all changed by the adoption of "REST", which is most definitely NOT a protocol -- there's no "P" in REST, is there? The only thing unique to REST is the philosophy that a URI can be more than a simple query response -- a notion that is fully understood in HTTP already. – Ninanincompoop

Answer 4

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

Ev

Answer 5

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.

Quadrille

REST is easier to maintain - all you have to do is monitor the API documentation for any minute changes to the structure of the REST methods or the structure of the data they return. If you see a change you will just have to manually make the change in your hand-written code which parses the response of the method. With SOAP you have the burden of right-clicking on your reference and selecting "update" and then fixing a few compile errors. (Sarcasm included free of charge.) – Hydrography

@JoshM: If you've hand-written code to parse the response of a generated response based upon a soft and flexible specification, you're not using REST; you've hardcoded to a resource tree. It's the same as coding to c:\windows\temp or whatever, as opposed to querying for the PROPER location to use. Because it works for a while, doesn't make it the right thing to do, nor is it good coding practice. – Jamey

@PaulSonier: what's the right way to parse the response from what often is a soft and flexible specification? I get that hardcoded brittle code isn't great, but I'm looking for advice or examples on the client end of RESTful APIs and coming up short so far. I think this is what Josh is getting at -- SOAP needs the ton of boilerplate code but what you get for that is a visible and enforceable contract on document format and type safety; RESTful APIs leave out the contract and the boilerplate and often look simple enough it doesn't matter, but... how do you not hardcode to the resource tree? – Surovy

(I get the HATEOAS argument, but using, say, martinfowler.com/articles/richardsonMaturityModel.html as an example -- there's still a fair amount of semantic interpretation needed, after parsing the XML, before you get to the link elements that are the "hypermedia controls".) – Surovy

If you dig into advanced features of SOAP (all the WS-* stuff), you'll quickly discover that tools don't support these so well (including EAI and ESB products) and that frameworks can behave differently depending (like Metro vs C#) for subtleties such as "" and null. And the generated boilerplate code is usually only to work around the burden cause by SOAP itself. – Terrarium

Answer 6

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.

Middendorf

Answer 7

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?

Hydrography

That is a nice answer but honestly, you do not understand what is REST. You can read the 2 best answers in this question to find it out. You are comparing them as a similar architectures, while REST being only a paradigm. It's the same as to compare "restaurant etiquette" with "pizza". Is it better to eat with a fork and a knife or to eat pizza? "I'd go with pizza" - you say. And as first answer suggests, you can easily use both - eat pizza with a fork and a knife. – Thalia

"In this day and age, do we really need to worry about a handful of bytes?" Umm, yes we do! From where I am, I can play many online computer games, but Blizzard's World of Warcraft Developers subscribed to your view and never bothered to optimize network traffic, hence its the only game I get constant disconnects from. For being such an old game, WoW has very heavy network traffic. That's not good in any day and age, because there will always be those with marginal connections where a wasteful approach to save you some development time will just break it. – Thoroughfare

In short, you seem to be saying, "SOAP is better because more tools exist to help you with it". While this is a valid point, be careful not to write off REST just because of this; it's easier to make a webpage in a WYSIWYG editor than to code HTML by hand, but that doesn't mean it's always the right answer. The value of REST is that it recognizes the HTTP spec created in the early 90s already solved many of the problems SOAP attempts to solve all over again. – Burge

@JoshM So your answer above is the same as your question from "#3286204"? – Sinner

@Sinner - guilty as charged...? – Hydrography

@JoshM if you are using Spring, I would say SOAP takes longer time with all the wsdl, xsd and other building blocks needed – Linguistics

@Linguistics This answer is over 5yrs old and I've since embraced REST a lot more! I still feel that a lot of my points are valid, though. – Hydrography

Rest can also use WSDL now so it have got advantages of contract now. Also REST supports WADL specification. – Steere

Answer 8

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.

Maighdlin

Answer 9

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

Lexicographer

+1 re "The best way to judge..." an good example is Google's Javascript API. Originally in SOAP, then in response to developer complaints, retooled in REST. Shortly after it became Google #1 API (by no. of requests)--surprised that it beats maps API but apparently it did (according to lead developer on JS API). – Shontashoo

Answer 10

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.

Reaction

"I'm sure Don Box created SOAP as a joke - 'look you can call RPC methods over the web'" probably true. +1 – Sinner

Answer 11

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).

Crony

Answer 12

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?)

Ecumenicist

Probably because you are wrong? REST can use any predefined or custom HTTP headers you need, plus the request body. – Huxham

Maybe not. Look at what you can put into a SOAP header vs. what you can put into an HTTP header. How long can the one line be? – Ecumenicist

The HTTP spec gives no limits on data included in headers and each header field value can span multiple lines. Individual web servers may impose moderate limits, but your implication that you cannot include significant information in HTTP headers is demonstrably false. – Huxham

@protonfish: I was not implying that you can't put significant information into HTTP headers. I was wondering if you can put as much information into HTTP headers as can be placed into SOAP headers. When I asked how long can one line be, it's because I wanted to know the answer. – Ecumenicist

@protonfish: I also thought that the distinction was clear between "the full expressiveness of XML" on one hand and "HTTP Headers and result codes" on the other hand. Perhaps that's not as clear as I thought. – Ecumenicist

@JohnSaunders its probably because you think there is some kind of restriction on the HTTP-Header. You should know that the entirety of all cookies from a webpage are simple part of the HTTP-Header. Many servers impose a custom limit of 81k (which is more than enough for anything you want to pass on with every request) - but most clients will accept data without limit there... – Happen

@Falco: I have no idea what leads you to believe that I don't understand HTTP. Among other things, I know that you can include XML in an HTTP header, after appropriate encoding. – Ecumenicist

I couldn't find any such limitation on the amount of data possible in HTTP headers (RFC 7230), but it's hard to argue that there is a huge difference in the expressiveness of XML versus the key-value pairs of HTTP headers. Not to mention that the HTTP headers are for HTTP requests and responses, and not for the applications doing the sending and receiving. That's where the SOAP headers come into play. I know it's probably just semantics, but that can be an important distinction for many people. – Yan

Answer 13

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.

Safeguard

Answer 14

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 "REST"... 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 "SOAP-REST" with "NON-SOAP-REST" in similar services,

• SOAP-REST (="REST-SOAP"): 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 "SOAP-REST".

• NON-SOAP-REST: any REST web service that can not be SOAP... That is, "90%" 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 "NON-REST-SOAP" with "NON-SOAP-REST", 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, "90%" of the well-knowed SOAP examples.

• NON-REST-NEITHER-SOAP: yes, the universe of "web services modeling" 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 "written agreements"),

  • 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 "verbose aspect" 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 "insurance policy" against any changes or noise.
  SOAP have "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", 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 "SOAP vs REST", 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). "REST NON-SOAP" (and XML-RPC, the SOAP originator) can be more simple and informal.

• The "only XML" 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 "PROS" section). PS: see a typical "B2B need for standards" described by @saille.

• Need for tools (see "PROS" section). PS: standards, and the existence of formal verifications (see bellow), are important issues for the tools automation.

• Parallel heavy processing (see "Context/Foundations" 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). "Sending the message along a path more complicated than request/response or over a transport that does not involve HTTP", 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 "flexible for an arbitrary number of client technologies and uses", 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 "Web software players", 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 "competing framework", 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 "any task": web services can be classified as
coarse-grained and embarrassing parallelism.

As the task gets bigger, it becomes less significant "complexity debate", and becomes more relevant the robustness of the communication and the solidity of the contracts.

Achene

I don't think this adds anything. It doesn't answer the original question or the three questions in my bounty: What features of a problem makes SOAP the better choice? What does SOAP make easier/harder? What does SOAP allow you to do that you can't do with REST? – Oreste

Thanks for the warning!... Well I try only a "2012's UPDATE" (!) that is the main thing, because not need repeat all arguments about "features ... SOAP the better choice ... make easier/harder ... can't do with REST". You not see at the other answers? I have more 5 days, perhaps you need a conclusion/summarization "to see a counterpoint to @Bracy answer", it is only it? PS: I will delete this comment after edits. – Achene

I want to know if SOAP is useful for anything, or if you should always use rest. If someone posts a reasonable reason for using SOAP instead of REST I will give that answer the bounty. If someone can explain why and how REST can do everything SOAP can I would give them the bounty. Otherwise I won't be awarding the bounty to any answer, and will add a comment to the question noting that I posted the bounty and an answer to my questions was not provided. (As I think it's useful to know what isn't known.) – Oreste

That's not what I want. And I don't see how WSDL is relevant. WSDL can describe SOAP or REST web services, you seem to be contradicting yourself. – Oreste

For similar discussion in "REST vs JSON-RPC", see https://mcmap.net/q/47524/-rest-vs-json-rpc-closed – Achene

Answer 15

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.

Trader

Answer 16

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.

1. REST uses standard HTTP so it is simplerto creating clients, developing APIs
2. REST permits many different data formats like XML, plain text, JSON, HTML where as SOAP only permits XML.
3. REST has better performance and scalability.
4. Rest and can be cached and SOAP can't
5. Built-in error handling where SOAP has No error handling
6. 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.

Sadonia

Answer 17

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.

Huxham

Answer 18

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.

Nahtanha

Answer 19

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.

Eastman

Answer 20

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.

Employ

Answer 21

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.

Benbow

Answer 22

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.

Gulp

(C) IBM ibm.com/developerworks/library/j-grails09168 – Brochette

Answer 23

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.

Astomatous

Answer 24

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).

Kaseykasha

Answer 25

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.

Scoggins

Answer 26

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

Exploiter

Answer 27

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.

Thorazine

Answer 28

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.

2. REST supports text,JSON,XML format. Hence more versatile for communicating between two applications. While SOAP supports only XML format for message communication.

Maurya