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

Formats with native hypermedia support

Expand Messages
  • Markus Lanthaler
    Hi, I m trying to create a list of formats with native hypermedia support (HTTP) that goes beyond just links supporting a GET.. So far my list is quite short
    Message 1 of 35 , Jan 17, 2012
      Hi,

      I'm trying to create a list of formats with native hypermedia support (HTTP)
      that goes beyond just links supporting a GET.. So far my list is quite short
      and I can't believe that that's all:

      - HTML (GET/POST/PUT)
      - Atom & AtomPub (GET/POST/PUT/DELETE)
      - WSDL (GET/POST/PUT/DELETE)
      - WADL (GET/POST/PUT/HEAD/DELETE)
      - Collection+JSON (GET/POST/PUT/DELETE)


      I'm sure I missed a lot. Do you know of any other formats?


      Thanks,
      Markus
    • Markus Lanthaler
      ... Is that really that clear? It is just the default behavior of browsers and thus, by far, the most common one (at least for HTTP, what about mailto, e.g.?).
      Message 35 of 35 , Jan 27, 2012
        > > I think that's interesting.. but I'm not clear where and how you
        > > would map these protocol-agnostic control elements to the various
        > > protocols/URI schemes, if you don't do it in the media type.
        > >
        >
        > Where does any such mapping exist for links in HTML?
        >
        > http://www.w3.org/TR/html4/struct/links.html
        >
        > Clearly, the semantics are retrieval

        Is that really that clear? It is just the default behavior of browsers and
        thus, by far, the most common one (at least for HTTP, what about mailto,
        e.g.?). The semantics depend, on the rel and rev attributes according to
        that document.


        > This change in scheme support affects all supported media types. It is
        > orthogonal to media type, so don't protocol-bind your media types.
        > HTML has seen protocols come and go, and will continue to be served over
        > HTTP 2.0 with yet another port # and URI scheme and perhaps different
        > method names

        That's true.. but I don't know how feasible that really is. HTML sits on top
        of an application level protocol (HTML or something else) which has its own
        semantics that might not always match 1:1 to HTML semantics.. Again, think
        of a mailto-link. How should a client retrieve such a "web resource"? It's
        simple not possible, and yet mailto-links and even forms work.


        > this has always made its HTTP form bindings look rather
        > quaint, IOW method='get' should be operation='retrieve' with no more
        > discussion of protocol than for <a> and <link/>, as in none whatsoever.

        But it wasn't specified that way. It was clearly bound to the HTTP methods..
        Nevertheless browsers are able map these HTTP semantics to other schemes -
        is that really any different? There's still time to change that for HTML5 if
        you think that it would be important to change this:

        http://dev.w3.org/html5/spec/Overview.html#attr-fs-method



        --
        Markus Lanthaler
        @markuslanthaler
      Your message has been successfully submitted and would be delivered to recipients shortly.