
Explaining REST to Damien Katz - baha_man
http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx
======
paul
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.

~~~
tlrobinson
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".

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

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

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

~~~
gigawatt
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
_Perhaps I judge too soon?_

Yes.

------
greenagain
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
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.

