Loading ...
Sorry, an error occurred while loading the content.

forms for web APIs

Expand Messages
  • Bill de hOra
    I got asked an interesting question a while back, for which I did not have a snappy answer - why aren t html forms a basis for an API? Other than the early
    Message 1 of 31 , Aug 3, 2008
    • 0 Attachment
      I got asked an interesting question a while back, for which I did not
      have a snappy answer - why aren't html forms a basis for an API? Other
      than the early blogging APIs being based on XML-RPC and eventually
      evolving into AtomPub I don't really know why forms with well-known
      query params aren't a a de-facto standard.

      Thoughts?

      Bill
    • Alexander Johannesen
      ... Quite. :) ... Kinda, but there s a few important points about this, as there can be many forms to do many different things per request. You can choose
      Message 31 of 31 , Aug 7, 2008
      • 0 Attachment
        On Fri, Aug 8, 2008 at 06:44, wahbedahbe <andrew.wahbe@...> wrote:
        > But this approach always has me asking: is this really so different
        > from RPC?

        Quite. :)

        > A form microformat or a set of standard query parameters aren't that
        > different than a standard function call. Your form is just saying "you
        > can make that standard function call here".

        Kinda, but there's a few important points about this, as there can be
        many forms to do many different things per request. You can choose
        which one to follow (just like on a normal web page with lots of
        links), as forms are in reality nothing more than a hyperlink with
        parameters. In REST one is to maintain client state on the client, and
        server state on the server, now accomplished through this mechanism.
        It has a further two advantages;

        1. Interfaces are discoverable, which means that if you change the
        server interface (order, direction, process, work flow), clients won't
        break as long as the semantics is sustained. 2. The semantics of
        application interfaces are shifted from the API itself (often through
        static binding of sorts) to an ontology layer that's easier to model
        and change over time.

        > So it offers a little more than straight RPC as you can discover when
        > and where you can make that call as you move through the hypermedia
        > state machine. But this model isn't quite right in my mind as it
        > constrains the server's interface too much.

        What are the constraints? The generic uniform interface, and
        coarse-grained semantics of MIME types?

        > Let me explain with an example: [...]
        >
        > For some reason, most "RESTful" machine to machine techniques don't
        > really give us this. I think most hypermedia formats being used are
        > missing mechanisms to translate from the client's model of the problem
        > to the HTTP requests of the service. In UI-oriented hypermedia, this
        > translation is left to the user. Don't you need to do something more
        > in the machine to machine case?

        No, what it is is that REST (or in our case, HTTP) is too abstract to
        be specific for that sort of functionality (in general), so the idea
        is to create protocols that are domain specific (or, more specific) to
        cater for that. For example, the AtomPub defines simple content
        management through their own MIME type.

        In your example, a booking protocol should probably be defined, and
        have its own MIME type as well. Interestingly, I'm working on a travel
        system these days and have something like that in place, although I
        use Topic Maps to denote shareable models and semantics instead of an
        agreed-upon document of prose.


        Alexander
        --
        ---------------------------------------------------------------------------
        Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
        ------------------------------------------ http://shelter.nu/blog/ --------
      Your message has been successfully submitted and would be delivered to recipients shortly.