use Perl

• Et tu, Brutus? (Score:1)

  by Aristotle (5147)

  I thought you of all people understood REST. :-(

  Presumably, if I had a sufficiently smart client that understood the media types used in the application, I’d point it at the root URI, it’d discover all the URIs, and I could manipulate and fetch data along the way.

  That’s a nice theory, but has very little with how people want to use these APIs.

  That’s not theory. That’s the web. Also, have you heard of something called AtomPub [ietf.org]? That’s like that, too. There are a lot of de
  • Re: (Score:2)

    by autarch (914)

    I thought you of all people understood REST.

    To be honest, I'd totally missed this part of it. I understand why Roy thinks it's important, but I'm not sure that I think it's important.

    My goals for doing something REST-like are several fold ...

    First, share the same URI space between what a browser sees and what a non-browser would see. This works quite well for everything that should be POST, PUT, and DELETE. For GETs, you end up with a bunch of stuff like /person/1/edit_form because browsers kind of suck, but that's ok.

    Second, by sharing that URI spac
    • Re: (Score:1)

      by Aristotle (5147)

      I imagine my media types would mostly be well-defined JSON “blobs”.

      Sure, that’s fine. Really, you don’t necessarily have to provide a specific media type; the core issue is that you document the response format, and that that format use links rather than application-specific IDs that the client must slot into URI templates which are never part of the in-band communication, and generally have to be built into the client at programming time.

      The other thing is, hopefully you would most