Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.

    • 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

      • 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

    • Not claiming to be that knowledgeable, but what made me "understand" REST was the book "RESTful Web Services" [oreilly.com]. That in turn cites the original thesis on REST [uci.edu]. 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 "representatio