Mike Champion asks;
[…]we all know what a service-oriented automated restaurant would look like — just like the human-powered service-oriented restaurants that have evolved over that last couple hundred years. What about a resource-oriented restaurant? I can see how that would work for fast food place (GET a menu, POST an order, which returns a URI one can GET the status of the order from ….). How about a real full-service restaurant, with a server who handles the details of the complex asynchronous interactions between a table full of people and a busy kitchen?
I could imagine an “order” document being submitted (POST) to the
kitchen, either directly by the customer, or indirectly via the server.
The server probably polls (GET) the kitchen on occasion in order to be
able to estimate arrival time of the meals, or discover when they’re
out of some ingredient. Or perhaps the kitchen notifies (POST) the
server. Or both. In a nutshell, documents moving around.
Is there any more complex scenarios I should cover?
Mike finishes up that paragraph with this;
Sure, one could implement those interactions with XML and HTTP, but would a system design
that talks about resources and representations really be more sensible than one that talks about services an
d requests?
I don’t know about “sensible”; that seems a rather subjective call.
But I do know that the resource oriented (RESTful) solution would exhibit
greater degrees of architectural properties such as scalability, visibility,
and simplicity than the service oriented solution, because RESTful solutions
embody architectural constraints which induce those properties.
Currently, REST leads SOAP $15.71 to 8.45. P.S. I bought REST, Javascript, and IE (it seemed way undervalued)
(
link) [
del.icio.us/distobj]
Jon Udell urges the REST movement to not dismiss SOA.
Specifically …
Now that the benefits of REST are abundantly clear, it’s time to circle back and ask when REST isn’t sufficient. The answer is that we’ll need the kinds of capabilities WS-* provides as our point-to-point, client/server-like applications evolve into webs of communicating services.
Yes, absolutey, we’ll need the capabilities that the
WS-* stack provides (for the most part). But do we need the WS-* stack
itself to provide those capabilities? I’m certainly all for trying to reuse
existing specs where that makes sense. The issue though, is that with
most of them, they explicitly or implicitly require disregarding
a key contraints of REST, disrespecting Web architecture, or both.
WSDL’s probably the poster child for this, as its raison d’etre is
primarily to encourage rejection of REST’s uniform interface.
The good news is that not all of the Web services specs have this problem.
Some off the top of my head that I consider more or less workable on
the Web (not to suggest that they’re otherwise without fault, and also
not to suggest I’ve had a serious look at every spec out there, even
these) include SOAP, WS-Security, and SAML. If that’s what Jon has in mind,
then we’re good to go. But if he was thinking about the likes of UDDI, the
various reliability specs, transactions, etc.., I’d have to disagree with
him. We need capabilities provided by solutions which were built with
the Web and REST in mind, like those of the Semantic Web and
ARRESTED.
Via Danny,
a question from
Julien Boyreau;
URI is first-class pillar in SemWeb AND Rest : do you know if there are large bridges between REST and SemWeb ?
There are a couple I’m aware of.
- Hash vs. Slash – when using
URIs with hashes to identify resources, REST’s resource identification constraint
(that resources be identified by a single datum, the URI in the case of the Web)
isn’t being respected
- RDF and media types –
the Semantic Web has a self-description problem in that there’s no path from an
application/rdf+xml OWL or RDFS message to the axiomatic triples it encapsulates.
Did the sender intend to communicate those triples to the recipient, or not?
More on that last point here.
It’s good to see John leaning towards REST. As for service description, I suppose having some use cases would help me understand the perceived need for one.
(
link) [
del.icio.us/distobj]
Jorge*n* Thelin (I mispelled his name before, my profuse apologies to Jorgen) catches up on his messages to me. Either that, or he’s obsessing. 8-)
I don’t know how I’m going to respond to all of that, especially in my weakened condition. For now I’ll just respond to the most recent one first.
Jorgen says;
I think the reason why Mark gets such pushback from his suggestions about defining the “architecture contraints” for Web Services technology is because I believe these principles don’t exist as specific “constraints” any more than the REST approach is a “constraint” defining the ONLY way to write applications that use the Web.
That’s true, constraints don’t “exist” per se. They’re just guidelines that are followed in order to realize useful properties. For example, when you’re driving your car, you follow certain constraints that serve to maximize the safety of yourself and other drivers, while still preserving the ability to get to point B from point A. Sure, you can ignore some constraints (like driving on the left hand side of the road 8-), but then useful properties (like your safety) are sacrificed.
It is still perfectly possible to write stateful web applications just as it is possible to write stateful web services. In both cases, it is bad practice to do this from many viewpoints (scalability being the obvious one), but it is certainly not completely precluded and actually in some scenarios there are no options but to use a stateful approach – it all depends on the application and usage scenario whether that is a valid approach.
That’s also true, but you have to realize that useful properties are being sacrificed if that’s done. Sometimes the sacrifice is worth the gain, but other times it is not. I’ve said before that I consider REST’s stateless constraint to be it’s second most important constraint. But it’s a far cry from the most important constraint, the uniform interface. I’d say that 95% of the Web’s utility and success derives from the useful properties induced by this one constraint. I cannot think of any reason why anybody would need to sacrifice this constraint that has worked so well. The reasons I’ve heard given, are that this constraint restricts the function of the architecture (equivalent to a “rule of the road” preventing you from driving to certain places), specifically that the Web is for humans, while Web services are for machines. But that’s simply not true.
Peter Drayton writes that some folks have had “RESTian awakenings” as a result of his presentation, which is just awesome. While reading up on one of his references though, I found this in Alexis Smirnov’s blog which suggests that at least some people still have a ways to go;
After his talk, Peter, Tim and Sam talked about a need to get a WSDL from a SOAP URI.
My response to that is, no, there is no need for WSDL. The fundamental advancement of the Web over previous distributed object systems is that it doesn’t need an interface language because all components expose a uniform interface.
An analogy; if you’re a Java programmer, think of it as working with all your objects after they’ve been downcast to java.lang.Object. Obviously java.lang.Object will only define methods which are common to all objects, so you wouldn’t expect it to have a method such as “buyBook” because not all objects are books. This is what REST’s uniform interface constraint is all about.