Re: Link relation types for non-GET links

[Erik Wilde <[e-mail]>]

hello klaus.

On 2015-08-13 08:03, Klaus Hartke wrote:
> Mike Amundsen wrote:
>> the IANA reg'd values "edit" and "edit-media" support unsafe (non-GET)
>> actions and are documented in RFC5023[1].
> So, is that the preferred way of doing things? Would it make sense to
> register a bunch of generic non-GET link relation types, like
> "create", "execute", "update", "delete"?

not any more than it would make sense to have a generic GET relation 
type that says "read"... link relation types should primarily indicate 
why somebody would want to follow a link. in HTTP-land, that may 
sometime require using methods other than GET, so that the uniform 
interface is used correctly. if so, the link relation definition (or the 
service making use of it) should say so, so that clients know how to 
engage in the interaction.

> It seems the syntax for links in RFC5988 and HAL needs to be extended
> for non-GET links to include a description of the representation that
> the service accepts when following the link (e.g., accepted media type
> and/or a set of form fields).

that get's rather complicated rather quickly. it has been attempted a 
couple of times, including by myself...

https://github.com/dret/I-D/tree/master/link-desc

the problem is where to draw the line, and that is hard to do outside of 
specific scenarios. for example, for W3C's LDP a simple HTTP header 
field did the trick (instead of embedding that info into the payload), 
so that's what they are using:

http://www.w3.org/TR/ldp/#header-accept-post

but that's quite a bit more limited what you seem to have in mind. 
however, defining a general-purpose format that captures all possible 
ways in which link relations may have rules associated with them is 
hard, and personally, my link description mentioned above draft has 
stalled because without a better picture of what should and shouldn't be 
covered, this is a typical "designing into the void" scenario.

cheers,

dret.

-- 
erik wilde | mailto:[e-mail]  -  tel:[phone] |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |