StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>SOAP is an <strong>object-oriented</strong>, <strong>remote procedure call</strong> technology stack. It works by building a new abstraction on top of an existing protocol (HTTP).</p> <p>REST is a <strong>document oriented</strong> approach, that simply uses the features of an existing protocol (HTTP). "REST" is just a buzzword -- the concept is this: Just use the web the way it was <em>designed</em> to work!</p> <p>In response to edits to question:</p> <ol> <li><p><strong>"Implementing a REST service takes infinitely longer than implementing a SOAP service."</strong></p> <p>Um, no, it can't be <em>infinitely</em> longer. And in cases where what you are trying to retrieve is <strong>already a document or file</strong>, it's actually <strong>much faster</strong>. For example, the OGC spec for WMS (Web Mapping Service) defines both a SOAP and REST version of the protocol, and there's a reason why almost nobody implements the SOAP version -- it's because if you're trying to get a map, it's a lot easier to just build a URL and fetch image bytes from that URL than it is to bother with encapsulating it into a SOAP message. But yes, I will agree that if the point of the web service is to transfer some strongly-typed object in a domain object model, SOAP is better suited for that use.</p></li> <li><p><strong>"Why write a REST service that returns XML anyway?"</strong></p> <p>Well, yes, that can be silly. But it depends on what the XML is. If there's a clearly defined schema for it somewhere, then there's no ambiguity. For example, you can think of WSDL URLs as being a kind of RESTful web service for retrieving information about a web service. In this case, adding the overhead of another SOAP request would be pointless.</p> <p>In general, REST wins when the content that is being transferred can be thought of as a <strong>file, as a single unit</strong>. SOAP wins when the content needs to be treated as an <strong>object with members</strong>.</p></li> <li><p><strong>"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?"</strong></p> <p>Yes. Not in every circumstance, but there are sites with a great deal of traffic where it makes a difference. Is it enough of a difference to outweigh the <strong>semantic differences</strong> of using SOAP instead of REST? I doubt it. If you're doing an object remoting protocol and the number of bytes is making a difference, SOAP is probably not the tool for you anyway -- maybe you should be using CORBA or DCOM instead.</p></li> <li><p><strong>"I've heard the argument that with REST you can just pop the URL into the browser and see the data."</strong></p> <p>Yes, and this is a large argument in favor of REST <strong>if it makes sense to view the data in a browser</strong>. For example, with image data, it's an easy way to debug the service -- just paste the URL into your browser's address bar and see what the image looks like. Or if the data returned is in XML, and you have a referenced XML stylesheet that renders into readable HTML in the browser, then you get the benefit of semantic markup and easy visualization all in one package. But you are correct, this benefit mostly evaporates when working with more complex authentication schemes. If you can't <strong>encode all your authentication information into each HTTP request</strong>, then I would argue that it doesn't count as REST at all.</p></li> <li><p><strong>"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?"</strong></p> <p>Well, it depends. Why do we need readable URLs for any resource on the web? You can read Tim Berners-Lee's essay <strong><a href="http://www.w3.org/Provider/Style/URI" rel="noreferrer">Cool URIs Don't Change</a></strong> for the rationale, but basically, as long as the resource may still be useful in the future, the URI for that resource should stay the same.</p> <p>Obviously, for transient resources (like the "today's Money" link in the essay) there is no need for it, since the need to reference the resource goes away if the corresponding resource goes away. But for more permanent resources (like StackOverflow questions, for example, or movies on IMDB), you want to have a URL that will work forever. When you're designing a web service, you need to decide if the resources themselves could outlive your service, and if so, then REST is probably the right way to go.</p></li> </ol> <p>For the record, yes, I've been developing web pages since well before NetFlix or Twitter existed. And no, I've not yet had any need or opportunity to implement a client to either NetFlix or Twitter's services. But even if their services are atrociously difficult to work with, that doesn't mean the technology they implemented their services on top of is bad -- only that those two implementations are bad.</p> <p>To make a long story short: REST and SOAP are <strong>just tools</strong>. They each have strengths and weaknesses. If the only tool you have is a hammer, then every problem looks like a nail. So get to know both tools, and learn how to use them correctly, and then choose the right tool for each job. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload