[…]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.