World Wide Webber

Interesting example but while a good introduction I'm concerned it may be too trivial an example. The biggest issue would be that a single order would often have multiple cups of coffee. It can increase the complexities of these processes dramatically. Now you have multiple parties, affecting multiple lines, either individually or in toto. Okay, maybe it would have made the article too long or confused readers. Otherwise quite good.

Hey James, 

I don't think I agree. An order is an order is an order. And while we chose a single coffee in that order (for simplicity as you point out), updating and receiving and order is pretty much the same whatever the content of the order. No? 

Jim

Some might say that is the same as saying "any big heavy metal object can be used as a hammer". True, but not the best way to do it. So for example, what are the rules that established the URI path rules? Updating an order is PUT {host}/Order/1234 but a payment is PUT {host}/Payment/Order/1234? Is the Payment an entity or is it being used as a verb? 

Would/should a multi-line order return a set of links so that each line could be individually updated/deleted? How do we distinguish between an update that affects the overall order (eg its position in the queue), and those that affect the individual coffess (low-fat chocolate on the cappucino, please!) 

What of a multi-relational, cross-dependant transaction...for example where you need to create both an employee and an office, neither of which is permitted to exist without the other? The difficulty, as I see it, is that in trying to remove the verb from the resource data, leaving it to the HTTProtocol, we may be complicating the process. Is REST incompatible with a Gang of 4 "Command Pattern"?

Hey James, 

The rules for establishing a URI are private to the server - that's the HATEOAS bit. Servers mint URIs and clients follow them. Any regularity in the URI is purely coincidental and (since we haven't given you a URI template) you're not invited to vary anything. 

A multiline order could return a set of links. Equally it could just be more of the same format - in that case we might even add a specialities link to each that you'd follow rather than doing the whole PUT thing. In fact that would be more hypermedia-ish too. 

In terms of the big transaction that you mention - I'd simply design differently. The Web isn't about end of unit-of-work concensus, it's about agreement at each step. 

REST is not a command pattern at all - you're dealing with updates to state which may cause commands to occur, but that's private. Nonetheless I'm confident that the command pattern isn't the only way to make scalable, robust systems and that (paradoxically) client/server with rich metadata (the Web) is just as feasible. 

Jim

I thought the main purpose of this great article was to clearly state that Starbucks Latte is by no means related to coffee. 

More seriously, my main concern is that someone might read this article and decide to create a framework out of it. Indeed, there is way too much design freedom in REST and HATEOAS for most people to feel comfortable about it (at least initially). 

Anyway, thank you for showing us the path, we now need to walk it!

Hey Jim -- this is a nice article; congrats on getting it published. 

I like the way you guys explain HATEOAS, but it seems like the resulting system relies on clients being implicitly well-behaved. That's rarely an assumption that we can make. 

Any thoughts on how you would address situations like the following: 

1) A client orders a drink but never pays for it 

2) A client pays for a drink but the barista never makes it 

3) The barista makes a drink but the client never picks it up 

4) The client picks up a drink that's not theirs, forcing the barista to remake somebody elses drink. 

5) A client asks the barista for an upgrade that requires them to pay extra (the add shot example is weak; Starbucks expects you to pay for that).  

I love to see a more fully worked example that accounted for these possibilities.

Hello Steve, 

Good points that you raise, and I can wholeheartedly say that we'll answer them all...in our forthcoming book :-) 

Can't give it all away now, can we? 

Jim

You've clearly got the consulting business mindset nailed :) :) :) 

Looking forward to the book...