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.

But I Like Docs, Roy! 3 Comments More | Login | Reply /

 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 mostly use well-known, extensible media types (eg. Atom) as the base content type for most of what you serve, so that clients actually don’t need to reimplement this parse-and-follow-links bit over and over. (Using a documented subset of XHTML works well when the structure of AtomPub does not quite match your needs: it’s XML and therefore easily parsed, but it’s also browser-navigable at the same time – very nice.)

        However, I’m not convinced it would be better to not document the URI space.

        It looks that way from the point of view of any one service, yes. You have to take a larger view to see that the point is not to have to write clients entirely from scratch for every single service, which ultimately benefits all of the individual services as well. (Imagine what would happen to the web if you had to use different browsers for different sites, or even just for different kinds of sites. Yet that is how we build programmatic agents today. AtomPub is the only large-scale exception I know of so far.)

        but not great for some other application which uses its own one-off media types.

        And then the question becomes, does it really need them? Most web services reinvent wheels in areas where that is not at all necessary.

        It really never discusses this aspect of REST.

        Yes. This criticism has been levelled against the book by many of the people in the REST circle. Sam’s response has always been along the lines of progressive disclosure [intertwingly.net] – which I kind of agree with, however I still think they needed to expound on this aspect at more length. It is really the cornerstone of REST – all of the other parts are in a sense groundwork laid down to enable hypermedia, which is the actual end goal, since that is how you achieve real decoupling.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.