(1) Fri Jun 25 2010 19:04How To Recognize Different Types of Web Service From Quite A Long Way Away:
As I emerge from the swamp of sickness, I bring you free stuff on the Internet. Today, it's a record of one of the two talks I gave at TriPZUG back in April when I went to North Carolina for WWW2010. The other talk, and my WWW2010 talk itself, will be forthcoming.

This talk is a quick exegesis of the "Richardson Maturity Model" for web services. If you want to get into it you can see the slides and hear the (slightly edited) recording. If you just want the stuff from my talk that's not in other, similar, discussions, here it is:

First, a clarification: some people think the Richardson Maturity Model is named after me, but that would violate Stigler's Law of Eponymy. It's actually named after my father.

Second: for this talk I identified three really simple questions you can ask to determine where a web service sits on the RMM:

Is there more than one URI?

Do URIs designate specific things? (As opposed to invoking actions.)

Are there any links?

Third, something I mention on the main talk page but that I'd like to give more exposure here and get feedback on. After the talk I got dinged by a friend for not giving a good
enough response to this question in the Q&A:

"We've been pounded with REST for the past ten years, and no one has
come up with a standard besides 'HTML' or 'XML', ad nauseum. Do you
see any resolution to that coming?"

What I said in response to that question was technically accurate,
but I didn't provide any advice. Here's my advice. You want a
good default choice that can settle arguments and save you from having
to make all the design decisions yourself? There is a standard: AtomPub. Take whatever you're
trying to do and make it fit the AtomPub paradigm. Not only will your
design be RESTful, your service will fit into a preexisting
ecosystem.

If you think AtomPub won't work with what you're trying to do,
you're probably wrong. Google, for instance, publishes
web services for many very different applications (spreadsheet,
calendar, map, etc. — basically anything that gets pluralized and has "Google" slapped on the front), and they're all based on AtomPub. You might find
a better fit with your problem space if you did a RESTful design from
scratch, but that's the nature of standards.