I’ve been meaning to do this for years now, but after a recent
about how poorly understood state is, I decided to make some time.
It’s no where near complete, as you can tell, but I think there’s
enough there to be useful to a lot of people. So I present to you, the
Of course, like any decent FAQ, it’s on a Wiki, so let’s work
together to make it better. Cheers!
I’ll be hanging out in Sunnyvale Jan 21-23, with the
morning of the Friday (21st), and the whole day Saturday, free.
Who wants to get together?
One thing’s for sure, I’ll be in the mood for a serious sushi outing.
Ottawa’s got to be the worst place on Planet Earth for it; no
sushi-only establishments, and of the
they don’t do omakase, and the sushi’s only barely passable!
Update; I suppose I should update this to say that Totoya is the first decent Sushi place I’ve found in Ottawa. It’s a bit on the expensive side, but their fish is by far the best I’ve had in town, and rivals meals I’ve had in Tokyo and Vancouver. Sushi 88 is nice as well; good variety and quite affordable, but not quite as tasty as Totoya.
I left a comment, but wanted to repost it here, since I think
this is the most succinct description I’ve offered for explaining
this critical point.
Nice job again Joe, but I think you’re a little (and I do mean *little* 8-) too rough on the existing service when you say “This is an RPC protocol trying to run over HTTP, and that misalignment is where the problems arise”. With the ListMyQueues and Read operations, putting them in a URI such that a GET returns the data *is* perfectly RESTful. This is because when in URI form, the effective operation – that which the client asks be done, and expects is done when receiving a successful response – is GET, not ListMyQueues.
It’s very(!) easy to
this point; the same point which is also, I believe, the principle impediment which
prevents proponents of document oriented Web services from realizing that REST and the
Web is what they’ve been trying to build.