mca blog

i've been following a thread on the REST Discuss list this week about the meaning/value of the "Hypermedia constraint" outlined in Roy Fielding's 2001 dissertation. from my POV, it's good to see folks wrestling with this aspect of the REST style. it leads me to believe that, even eight years after it's publication, Fielding's work is continues to connect with folks interested in applying the concepts in real-world situations.

this thread is a bit 'rangy' and covers a number of things. one of them is the notion that the "rel" link attribute might contain additional useful information to help clients navigate state transitions. this idea has also been the subject of discussions by Savas Parastatidis and Jim Webber recently.

i, too, have been working on this notion of 'decorating' links w/ rel values in order to add more content for state engines to use. along the way, i've come to some fundamental issues on the matter. i post them here in hopes of inviting response to clarify, refute, dispel them as is appropriate.

• if rel values on links are to be useful for state engines, then the semantic meaning of the values need to be understood by clients and servers. this leads me to think that a standard is needed. like rel="stylesheet", but on a grander scale
• if rel values are to be useful for machine-to-machine interactions, a wide number of clients need ways to translate the rel into predictable actions.
• if rel value are to be useful for human to machine interactions, they need to be rendered for humans to see. this should probably occur in a standard way was well. titles, roll-overs, colors, locations on the screen (i.e. navigation, etc.) are all possiblities
• many examples of these types of rel values involve not just navigating to the URI in order to make the state transition, but also require supplying additional information (in the form of a state representation) to the server. for example, rel="payment" probably requires additional data such as a credit card number, etc. is this just an HTML form element? or is there something else needed here?
• thinking again about machine-to-machine interactions, does the server need to send more than one hyper-link to the agent at any point? in other words, does the client really 'choose' from more than one link? or does the client start somewhere (the public URI) and, through passing state representations, navigate a single path provided by the server that is the result of the state representations passed by the client?

there has certainly been some effort to standardize rel values:

• the HTML 4.0 docs define the rel value as a simple text annotation (with the exception of stylesheet).
• the RDFa spec adds a few more string values for rel.
• the Atom spec has defined rel values, too.
• Mark Nottingham's Web Linking Internet Draft contains details on how new rel values would be registered w/ the IANA

so, does it make sense to work toward standardizing rel in a way that would aid in building hypermedia state engines? i mean to say, it is reasonable to think that a well-defined set of rel values can make it easier to build state engines that can perform machine-to-machine interactions with greater reliability? can these standardized rel values improve the human-to-machine interaction as well?