Exposing resources for machine consumption isn’t any different than exposing resources for human consumption until you get down to the media type.

A lot of web developers fail to see this.

Excellent commentary on the high/low REST coinage:

Mark Nottingham: Don’s False Choice

The problem is that one man’s 98% are another’s 55%.

All I was talking about is an idempotent portion of a system (an exactly measurable feature). How you inferred that one man’s 98% of idempotency is another’s 55% is beyond the grasping capabilities of my feeble mind.

I am strongly convinced that the reason that RSS seems to be holding up (which I will assume means RSS 2.0, since earlier versions are RDF, even if noone parses them that way) is that it hasn’t been pushed. It’s not used for anything much other than shovelling weblog content into readers, which content consists mostly of tag soup anyway. So the fact that RSS seems to work is really no more to the point than the fact that HTML tag soup seems to work.

I do agree with your basic thesis that REST succeeds because of the REST principles and does not depend much on the wire format. The position you put forth in the article just seemed to veer into “we’d be better off without XML,” rather than staying on the “XML isn’t what matters” course, so that’s what I addressed in my comment.

Alex,

don’t be silly. You won’t find many who will argue that excessive model complexity is worth its diminishing coverage returns. People aren’t stupid. The problem is that one man’s 98% are another’s 55%. People disagree about how much of the problem space constitutes the 80% worth addressing. Your portrayal of the problem conveniently skips over the hard part; unfortunately, reality is rarely that tractable.

In some cases, I get most mileage out of using microformats, and everything else is just a layer of indirection. But microformats have their limits, and in other cases XML works better. RSS are great for some stuff, they’re an overkill if you’re doing an authentication API. And let’s not forget JSON.

You can write a whole article on what to use when, I think that would be useful. But the key point is discretion: use all of these, but for each use case pick the ones that are most effective.

The only barrier to using XML and RSS and microformats and JSON is learning. The barrier to using XML when you should be using microformats, or RSS when you should be using JSON is complex code that’s difficult to write and maintain.

As for REST, I follow the same approach. Which means most of my Web stuff break REST by relying on cookies, and most of my APIs break REST by asking you to construct URLs. And so far I’ve only had use for GET/POST.

I call it lightweight services. It’s about keeping services simple to implement, use and maintain. And it so happens that a lot of REST gets used because REST fits the bill.