Explaining REST to Damien Katz

http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx

by baha_man • 18 years ago

51 20 18 years ago

tptacek• 18 years ago

Apropos nothing, Dare Obasanjo needs to seriously reconsider the use of boldface as his link style.

gigawatt• 18 years ago

Equally apropos of nothing, I saw his tagline and decided to never read anything on his site. Marketing yourself as an alcoholic pothead programmer seems a strange choice. Perhaps I judge too soon?

pius• 18 years ago

Perhaps I judge too soon?

Yes.

paul3• 18 years ago

Part of the problem with these REST discussions is that the definition of what is being discussed keeps shifting. The reasonable bits of REST are, well, reasonable, and generally non-controversial.

Most of what he describes in this post is fairly reasonable, but his previous REST post (that I mentioned as silly) focused on the less reasonable (and more dogmatic) parts. He criticized APIs for such things as, "REST API Sin #1: URIs Identify Methods Instead of Resources (The Original Sin)". Referring to design decisions as "sins" may be cute, but it's also a clue that you may be drifting away from pragmatism and towards religion.

tlrobinson2• 18 years ago

Agreed. I think there's a couple issues that cause confusion.

Yes, REST advocates say your URLs should be for "resources" not "methods", but sometimes the distinction is blurry. For example, a Google search: http://www.google.com/search?q=restful

Is www.google.com/search a "resource" or a "method"? I would call it a method, but it's also sort of a resource. I can't think of any way to make it more "resource oriented".

jsdalton• 18 years ago

It's more like a collection or list of resources, and the search term is a filter on that collection.

bct3• 18 years ago

> Is www.google.com/search a "resource" or a "method"?

You can look at it either way, but it's a perfectly fine resource.

sh1mmer4• 18 years ago

Well yes, that is sort of true. But, if it were most other subjects people wouldn't give a crap. It's hard to say what it is about pure REST that works people up so much.

I think, perhaps, it's hard for people to be told they don't get REST when they thought they did but were actually doing a REST-RPC hybrid.

tlrobinson2• 18 years ago

"It's hard to say what it is about pure REST that works people up so much."

I think a comment on Damien's blog summed it up nicely:

"I love living in the modern age.

It's so refreshing to have moved from religious fights based on the Bible to religious fights based on RFCs."

paul3• 18 years ago

The thing is, there's nothing wrong with doing REST-RPC hybrid. The reasonable parts of REST (like making things stateless, using http error codes, etc) are just as reasonable with RPC, and often RPC is the right way to approach an API (better than pure REST).

greenagain• 18 years ago

I think that Damien's point is that he doesn't get the "self-evidence" or Good Thinginess of using REST as a _developer_ of a web application. I see it over and over again in development situations: As soon as the topic of webservices comes up, someone starts crying, "REST! REST! OMG, REST!" And that's usually before they've even heard what the web service will do.

It's funny: When REST advocates are pressed about how REST might not be the best choice for every, single development effort, they either:

1. Simply regurgitate REST's tenants 2. Deny that they are regurgitating REST's tenants, and then go on to regurgitate REST's tenants

I think that everyone can acknowledge the good of using REST as a _user_ of a web application -- which is what the REST literature addresses anyway. But is REST going help app developers deliver features in a timely manner? Is it the most agile way to develop? Not necessarily.

<controversial>If you follow REST to its purist implications, you probably wouldn't have a dynamic web application at all. Instead, you'd have a interlinked mesh of of hand-written HTML pages that cover every representation of the application. Hello, Early Web!</controversial>

So anyway, if REST works for you, awesome; as long as you've designed your resources and interfaces intelligibly, you're helping to make the waters of the internet easier to navigate. It SOAP/RPC isn't working for you, maybe you should try REST. But if SOAP/RPC is serving you just fine, don't let this topic rock your boat.

sabat• 18 years ago

For the record, Dave Winer didn't come up with SOAP, and didn't do with a "bunch of folks from Microsoft". SOAP sucks and it's largely due to MS' influence, but Winer merely came up with XML-RPC, which is pretty close to Damien's idea that maybe POST is enough.

Not that I'm a Winer fan -- his behavior oddly reflects his surname -- but facts is facts. Dave understands the need for simplicity, and needless to say, the SOAP folks don't.

Explaining REST to Damien Katz

Related Stories