Formats with native hypermedia support
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?
> > I think that's interesting.. but I'm not clear where and how youIs that really that clear? It is just the default behavior of browsers and
> > 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?
> Clearly, the semantics are retrieval
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
> This change in scheme support affects all supported media types. It isThat's true.. but I don't know how feasible that really is. HTML sits on top
> 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
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 ratherBut it wasn't specified that way. It was clearly bound to the HTTP methods..
> quaint, IOW method='get' should be operation='retrieve' with no more
> discussion of protocol than for <a> and <link/>, as in none whatsoever.
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: