Thank you for your attention.
Hi
Quite possibly not.
I did say I was trying to clarify my ideas.
And, like all learners (yes, even you), I have to go thru a learning phase.
Life, Perl and REST are all topics to be learned.
Fundamentally, that means I do not possess absolute or infinite knowledge, and never will.
If I get things wrong, it doesn't matter. What matters is whether or not I get feedback in a form which helps me correct my misunderstandings.
And if I keep my misunderstandings to myself, they'll never be corrected. So - what can I do but broadcast them. Hence the article.
Re:No such thing
Aristotle on 2009-10-10T01:38:23
You may have triggered the post, but it was not specifically addressed at you. A lot of people make this mistake.
Thing is: URI design and REST are orthogonal to each other. They are both good concerns, mind – they just have no dependency on each other. URIs can be messy and ugly and yet the system RESTful – or they can be clean and simple and yet the system effectively RPC-style. However, since people writing RPC-style services tend not to care about URIs, caring about URI design is often taken as a shorthand for doing RESTful design. The predictable result is that people, eg. you, build RPC-style systems with clean URIs.
It’d take a long-winded post to address the misconceptions, though… I just couldn’t be bothered to say more at this time.
So, this was not some kind of passive-aggressive put-down.
Re:No such thing
Ron Savage on 2009-10-11T02:42:00
Hi Aristotle
$many x $thanx for your clarification.
I felt it was no shorter that it needed to be, i.e. it said everything it needed to.
I did not take it negatively. I've extremely appreciative of the fact that it was not meant as a put-down, unlike some mailing lists which specialize in browbeating posters who don't know everything.
I've re-worked the article.
Cheers
Re:No such thing
slanning on 2009-10-10T12:32:01
Not claiming to be that knowledgeable, but what made me "understand" REST was the book "RESTful Web Services". That in turn cites the original thesis on REST. Some ideas that I took away were:
- keep a uniform interface, which is what the HTTP methods already give you;
- give every "resource" in your application a(t least one) URL;
- avoid keeping application state on the server, for scalability;
- hyperlinks send the application from state to state on the client side, in other words the current state's "representation" has links from the current state to whatever next states there are in the application (or to other applications, e.g. externally-linking URLs)
The last one is "REpresentational State Transfer".
