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

    • 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

      • 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