use Perl

• No such thing (Score:1)

  by Ron Savage (5224)

  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
  • Re: (Score:1)

    by Aristotle (5147)

    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
    • Re: (Score:1)

      by Ron Savage (5224)

      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: (Score:0)

    by slanning (5049)

    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