Adam
Bosworth: I admit to not being a REST expert and the people
commenting, Mike Dierkin and Mark Baker in particular, certainly
are. They tell me I'm all wet about the REST issues. I'll dig into
it. But I admit, I don't get it. I need to be educated.
I personally think that the place to start is to first tease
apart the "HTTP is the one true protocol" from the "REST is the one
true architecture", and then initially focus on the latter.
Once done, you may come back to believe in one or both of these,
but they can be addressed independently.
To draw an analogy, Java 1.0 did not have a component
model. A convention of getters and setters methods
corresponding to a property emerged. Getters always have zero
parameters, setters typically have one.
On the web, there is an analogous component model.
Resources have a GET and POST method (as well as a few
others). This is not one per property, but one per resource
(object). This encourages a coarse grained approach to
integration - something that scales better than fine grained
access.
Nothing in REST requires or precludes an equivalent to
WSDL. However, nothing in WSDL today models the interaction
that is typical of WSDL itself: "at this address is a document of a
given type. If you GET it, you will find a strongly typed
description of another resource (endpoint)".
Anybody with experience in database design will tell you that it
makes sense to focus a lot of energy on optimizing reads. The
web does this well.
Other principles that apply: all persistent resources have
identifiers. No implicit state.
In several ways, Adam's questions seem like "my newly architected tools (SOAP) do these things, how does your architected tools (REST) handle them?" It's a good question but shows where the disconnect lies: REST isn't a tool or a spec. Most of those questions are very good questions for "how do you do define specs that support these things and are RESTful."
In many ways, the original SOAP direction was an entirely new direction for web architecture, or at least the area of web services architecture. Over the last few iterations, we've seen SOAP actually pick up more of the web architecture (document literal, the nod to HTTP GET) as some of the lightbulbs go on. Going forward, I hope more of the lightbulbs are in the area of "how do we solve these architectural problems, without locking the solution into one protocol (SOAP)". In other words, there are great solutions within the SOAP stack that can be extracted and applied across the board to many types of interactions and formats, and thus be RESTful and not just tied to SOAP.
I hope this doesn't totally confuse the issue, but I wanted to make a further clarification about REST and Web Architecture: Web Architecture (URIs, access protocol schemes, and related media types) is an instance of the REST Architectural Style. SQL (CRUD, specifically), Unix's "everything is a file", Linda's TupleSpaces and Jini's JavaSpaces are all also instances of REST, wholly distinct from Web Architecture.
It's interesting to note that REST instances are virtually all data-driven. The battle for the future of web services, and scaling thereof, is based on the long debated issue of data-driven systems vs. behavior-driven systems.
+1 to both Sam and Ken, except for Ken's 2nd last paragraph; none of those things are RESTful, though they share some important qualities, in particular being built around an abstraction. REST says that abstraction MUST be the resource, whereas all of those Ken lists are more specific than that.
I can see that SQL and TupleSpaces are more specific, and may fail to qualify as truly RESTful.
But the Unix file system? It's all about the abstraction of the resource. Maybe you're referring to implementation, where not as many things are abstracted as files as "could be" in common Unixes, unlike, say, Plan 9 or the Hurd, or various virtual file systems like Gnome's Midnight Commander.
Yes, REST is an architecture, not a particular tool, but the fact is that the current crop of tools for HTTP (and thereby, REST, at least for Internet apps) suck, and actively encourage people to write Web applications that don't leverage the Web architecture.
Under these conditions, it's completely reasonable for Adam to ask what tool support there is for REST; given that HTTP, at least, has had a reasonable amount of time to bake, it's instructive to see what's available for it.
P.S. - I do agree that it's behaviour vs.data; it's still difficult for Web services people to think in terms of representations of state.
I think one part of the issue is that when it was decided that "the web doesn't do <this>", and what was really in mind was "HTTP doesn't do <this>", the decision was, "let's put forth the work effort to create a new protocol that does <this>" instead of "let's put forth work effort to extend the web to do <this>, maybe by extending or creating protocols and formats within the web."
The subtlety underlying all of this discussion is explaining why SOAP itself isn't extending the Web in that sense.
It's obviously trivial to build a non-REST system with HTTP and, say, XML only. I wonder: If REST is truly an architectural style, and not tied to the HTTP protocol, isn't it possible to build a REST-conforming system using SOAP, WSDL, and whatever WS-* standard might be useful for a particular scenario? That is, given the current state of the SOAP and WSDL specs, isn't it just a matter of how you use your tools instead of what tools you use?
Thanks for the pointer, a very interesting read that I must have missed somehow!
What seems strange to me is that I perceive a lot of REST proponents as being extremely zealous about the whole idea, without being able to see any value in the SOAP proponents' opinion, while the reverse is definitely not true. Useful URIs most definitely have great value -- as long as they actually do refer to resources, and are not used artificially just because one tries to force everything into a REST scheme.
Hang on, I'm a REST proponent and a SOAP proponent, so be careful when pigeon-holing.
As long as you don't put methods in the SOAP body - which I don't do - I'm quite happy.
What's that you say, that's document style SOAP? Well, goodie. Now assign a URI to the thing whose state is represented by that document and we're done; instant Web.
Ken, you may have me on the file analogy ala Plan 9. But then again that's just the uniform interface constraint, and doesn't include hypermedia, self-description, etc..
Mark - you're a SOAP proponent? I am speechless ;-)
I am still not 100% with you on the "document-style SOAP+URI equals REST", though; from my (admittedly limited) understanding, I feel that a document (in the way the word is used by the document-oriented Web Services guys, is intended to be utterly self contained and just transported via different protocols. Note that I'm not claiming that this is in any way better, just different from REST's GET/PUT/POST/DELETE semantics. From this point of view, a purchase order is something that does indeed request something from somebody else, as opposed to something that captures the state of a purchase.
Yes, I'm a big SOAP fan. Just not a Web services fan.
I was an active member of the XML Protocol WG for about 18 months I think (for two companies; Sun, and my own), trying to ensure that SOAP could be used RESTfully. And here's something to knock your socks off; when used propertly, it actually makes HTTP more RESTful (specifcally, more self-descriptive)! Yes, you heard me right.
Ponder this; if you "transport a purchase order" (the paper kind) to a paper shredding service, are you asking them to shred the order, or asking them to fulfill it?
The REST style specifically says that "hypertext" is the engine of application state. Now some of us are defining "hypertext" to roughly mean navigable links. Perhaps a subtle point, but if you are using some kind of format that doesn't support linking with URIs, you're probably not using hypertext then.
Is SQL self-describing? If not, then SQL isn't part of REST because REST requires self-describing data (that whole dispatch thang).
While the Web is certainly optimized for reads, the problem is that often times the reads we want to do in Web services can't be formatted into URIs. How do I make a query based upon a complex document with URIs in the document? Can't do it with GET. Now some of us also thought of recommending a new HTTP "safe" verb that took a body, call it "QUERY". But we decided not to recommend it because the chances of a new version of HTTP being deployed any time soon are next to zilch.
Yes, I'm a big SOAP fan. Just not a Web services fan.
You have me confused - especially with the lowercase s in services ;-)
I don't really care about the label you stick to things; it's plain that there is a lot of intelligent effort being invested in both SOAP and REST, and if everybody agrees that these are not in conflict, it can only be a good thing.
Ponder this; if you "transport a purchase order" (the paper kind) to a paper shredding service, are you asking them to shred the order, or asking them to fulfill it?
This is turning into a kind of philosophical debate. To me, a purchase order is a purchase order - it describes the buyer's desire to purchase something from a supplier. Whether it's currently being approved internally, fulfilled, or archived (you're not really going to shred those things, are you? ;-)) is, IMHO, part of the larger state of the purchase.
But analogies only can go so far; you can clearly attach semantic meaning to the transfer part (which would be the REST way, I presume), or you can emphasize the document's self-describing nature. I tend to the latter view, but more importantly, I view both as equally valid and can see no proof that one is better than the other.
"But analogies only can go so far; you can clearly attach semantic meaning to the transfer part (which would be the REST way, I presume), or you can emphasize the document's self-describing nature."
REST does both. REST message are completely self-describing by definition, as it includes the "self descriptive" constraint 8-).
You can also just use "document transport" and have it be self-describing, but at the cost of extensibility; that you can't infer semantics different than those assumed by the transport action (well, mostly). To illustrate the difference, consider these messages which contain the same document;
"<hello xmlns="http://foo.example.org"/>"
"PROCESS <hello xmlns="http://foo.example.org"/>"
Both can be fully self-descriptive, but the latter reflects a more extensible interface. So that interface can be extended, ala;
The W3C markup validation service clearly spells out three separate places where it looks for character encoding information: one in an HTTP header, and two within the payload itself. Despite this, in neither of these web pages can this most basic of information be found.
Hmm, it turns out I had the XML declaration correct (iso-8859-1). I fixed the other problems in the site (improperly nested "ul"s, & -> & in URIs), and now it's fine. Very odd.
Everyone knows how much I respect Sam Ruby. A lot of the projects into which he's poured his time, energy, and veritably Buddha-like patience are so difficult and so thankless that they qualify as pure public-service rather than itch-scratching in my boo...
[more]