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 desktop weblog publishing client that use it.

    Without prior documentation on what the URIs are, how would I implement my client?

    Yeah, how? How did these people write weblog clients against AtomPub?

    How does my client know which URI is which without manual intervention?

    Because it saw something like <link rel="search" href="..."/> (in the case of Atom) in some other response body it already received.

    I can’t even figure this out.

    Read the AtomPub spec.

    Fielding’s REST basically rules out casual implementers and users

    Nonsense, I’m afraid. (Quite the opposite, actually, it invites reuse in the small in a way that RPC-ish systems cannot – Roy terms this “engineering for serendipity”.)

    since you have to build a complete implementation of all the media types in advance.

    How do you write a program that can do something with information it has no way of parsing?

    A “truly RESTful API”, in response to a search query, responds not with the information asked for, but a list of links! So if I do a search for movies and I get a hundred movies back, what I really get is a summary (title and short description, maybe) and a bunch of links. Then if I want to learn more about each movie I have to request each of 100 different URIs separately!

    You’re twisting Roy’s words in his mouth. Atom feeds can contain the full data for each entry, and if you ask Roy what he thinks about AtomPub, he will tell you it is a great example of getting REST right. The salient point is that the Atom feed contains the URI of any entry that has one, and that is what you use to manipulate the entry if you want to do so.

    • 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

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