StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>An honest question deserves an honest answer. But first, why did you use the text of this question as an <a href="https://stackoverflow.com/questions/76595/soap-or-rest/3322449#3322449">answer to another question</a> if you did not think it was rhetorical in nature?</p> <p>Anyway:</p> <ol> <li><p>"<strong>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 by reading documentation.</strong>" </p> <p>Just like browser vendors have read and re-read the HTML 4.01 specification up and down to try to implement a consistent browsing experience. Have you reflected on the fact that browsers were invented long before internet banking and stackoverflow, and yet, you can use a browser to do just those things. This is made possible because of the sole reason that everybody agrees to use HTML (and related formats like CSS, JS, JPEG etc).</p> <p>Blogging is actually not that new, and someone came up with AtomPub, which allows any blogging software to access and update posts in a blog, much like any web browser can access any web page. That's pretty neat, and works because of the RESTful constraints imposed by the protocol.</p> <p>But for Twitter and Netflix, there is no universal agreement that "all microblogs in existence shall use the media type application/tweet", mainly because microblogging is so new. Maybe in a few years time a few microblogging services settle on the same API so that Twitter, Facebook, Identica and can interoperate. None of their existing APIs are anywhere near RESTful, however much they claim, so I don't expect it to happen real soon.</p> <p>"<strong>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.</strong>"</p> <p>You've hit the nail on the head. REST is all about distributed and hypermedia, and that pretty much sums it up. A browser looks at what it gets from a request and shows it to the user. A HTML page usually spawns a lot more GET requests, for example CSS, scripts and images. An image is typically only rendered to the screen, JavaScript is executed, and so on. Each time, the browser does what it does because it found the link in an <code><img></code> or <code><style></code> tag and the response media type was <code>image/jpeg</code> or <code>text/css</code>.</p> <p>If Twitter makes a hypermedia based API, it will probably always return an <code>application/tweet</code> every time you follow a link to a tweet, but the client should never assume it, and always check what it gets before acting on it.</p></li> <li><p>"<strong>Why write a REST service that returns XML anyway?</strong>"</p> <p>This all boils down to media types. Like HTML, if you see an element that you've no idea what actually means, the HTML spec instructs you to ignore them, and process the "body" of the tag if it has one. Likewise, the atom spec instructs you to ignore unknown elements and foreign markup (from different namespaces) and <em>not</em> process the body (IIRC).</p> <p>Designing media types for generic problem domains (as in the <em>HTML</em> media type for the <em>rich text</em> problem domain) is very hard. Making media types for very narrow problem domains is probably a lot easier (like a tweet). But it's always a good idea to design for extensibility and specify how clients (and servers) are supposed to react when they see elements or data items that don't match the spec. JPEG, for example has an Application-specific record type (e.g. APP1) which is used to contain all sorts of meta data.</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>No, we don't. REST is absolutely not about being efficient over the wire, it's actually trading wire efficiency in. REST's efficiency comes from the possibilities of caching enabled by all the other constraints: <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_5" rel="nofollow noreferrer">Fielding's dissertation</a> notes: <em>The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.</em> I don't think that the SOAP Envelope byte count overhead is a valid concern.</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, that's also an invalid argument. It doesn't work that way. Even if it did work, most <em>narrow</em> REST APIs out there use media types that browsers have no idea about and it still won't work.</p> <p>But there are a lot more possibilities than a browser to test a HTTP based API, like command line utilities or browser extensions that allow you to control almost any aspect of a HTTP request, inspect response headers and discover links for you to follow. But even so, this is nowhere near as easy as generating WSDL stubs and making a three line program to call the function anyway.</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>If you look at how the web works, I'm pretty sure that humans are by and large glad that the URI for a wikipedia page looks like this, <code>http://en.wikipedia.org/wiki/Stack_overflow</code> instead of <code>http://en.wikipedia.org/wiki/?oldid=376349090</code>. But it actually is not important to REST. The important thing to try to get right is to choose to place relevant data in the URI that is not likely to change. You might think that the database ID will never change, but what happens when two data sets need to be merged? All your primary keys change. The page title (Stack_overflow) will not change.</p></li> </ol> <p>Sorry for the long response, but I believe this question is valid, and hasn't been addressed before here on SO. I'm sure Darrel Miller will add his answer once he's back too.</p> <p>Edit: formatting</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