you're reading...
FYI, Linked Data

HATEOS revisited – RDFa to the rescue?

One of the often overlooked, IMO yet important features of RESTful applications is “hypermedia as the engine of application state” (or HATEOS as RESTafarians prefer it ;) – Roy commented on this issue a while ago:

When representations are provided in hypertext form with typed relations (using microformats of HTML, RDF in N3 or XML, or even SVG), then automated agents can traverse these applications almost as well as any human. There are plenty of examples in the linked data communities. More important to me is that the same design reflects good human-Web design, and thus we can design the protocols to support both machine and human-driven applications by following the same architectural style.

As far as I can tell, most people get the stuff (more or less) right concerning nouns (resources, URIs) and verbs (HTTP methods such as GET, POST, etc.) but neglect the HATEOS part. I’m not sure why this is so, but for a start let’s have a look at available formats:

  • Most obviously one can use HTML with its official link types or with microformats (for historic reasons see also a proposal for a wider spectrum of link types and for ongoing discussions you might want to keep an eye on the @rel attribute discussion).
  • Many people use Atom (concerning RDF, see also the interesting discussion via Ed Summer’s blog)
  • There are a few non-standard, in-house solutions (for example the one discussed in an InfoQ article)

Summing up, one could understand that there is a need for a standard format that allows to represent typed links in an extensible way and is able to serve humans and machines. In 2008 I argued that RDFa is very well suited for Linked Data and now I’m about to extend this slightly: one very good way to realise HATEOS is indeed RDFa.

Happy to hear your thoughts about this (admittedly bold) statement!

About these ads

About woddiscovery

Web of Data researcher and practitioner


7 thoughts on “HATEOS revisited – RDFa to the rescue?

  1. Another good (better?) way is via Link headers, since it lifts the burden on content-types to be used in the responses’ entity-bodies and therefore maintains HATEOAS regardless of the hypermedia abilities of the format (png, jpeg, whatever).

    Posted by Mike | 2009-12-15, 11:07
  2. I’d go along with Mike. RDfa is great for adding some linked data to an existing app/templates, and where it’s not practical to return the raw (linked) data, but can fall down badly when serving more complicated sets, with the HTML and RDF fighting each other and with the result that both are compromised.

    303 redirects and content negotiation is fairly straightforward to implement for a new app (at least compared with writing the actual RDF!)

    Posted by countculture | 2009-12-15, 12:25
  3. “Hypermedia as the engine of application state” sounds interesting, but even after looking at the section of Fielding’s dissertation you pointed to I can’t discern what it means. Could you say more about that? Or point me to where I should look?

    Posted by Jodi Schneider | 2009-12-16, 16:25
  4. I think RDFa is a great way to realize HATEOAS. As a fan of both linked data and the “rest of REST”, realizing HATEOAS in RDFa saves a client from understanding different custom XML representations of linking, including ATOM. I’m also a big fan of XHTML (with RDFa) data representations and thus, generally go with XHTML and JSON as supported content types in my initial implementations of services and rarely get any client requests for XML.

    @countculture, I don’t think RDFa or any HATEOAS implementation should override or compliment content negotiation, that is still necessary as part of the HTTP layer. As for 303 redirects, the rfc says “The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).” which lends itself perfectly to RDFa.

    Posted by Jason Pearlman | 2009-12-21, 03:03
  5. Jason, I think countculture referred to the other main way of serving up RDF descriptions, that being RDF/XML, which is often provided after a 303 redirect from the URI to be described. Since they too (potentially) comprise Linked Data, RDF/XML descriptions can be used for navigating an application just as well as RDFa—except you don’t need to reconcile the human-readable HTML and machine-readable RDF in one document.

    But so far there don’t seem to be any moves by the major search engines (read: Yahoo! and Google) to support RDF/XML, so many publishers are compelled to include RDFa anyway. Or am I missing something?

    Posted by Vasiliy Faronov | 2009-12-26, 20:16
  6. @Vasiliy Faronov Dead right. The search engine issue (indexing RDFa, but not RDF/XML or RDF/JSON for that matter) is ptentially a serious handicap, as by moving to full-blown RDF from RDFa (with more data than can be served by RDFa) you are penalised by them.

    I’m sure as the linked-data universe grows this will become less of a problem, but it’s definitely a consideration at the moment.

    Posted by countculture | 2009-12-27, 13:53
  7. I’ve been reading Roy’s dissertation repeatedly over the last week to glean as much understanding from it as I can.

    As far as HATEOAS is concerned, I think it refers to the fact that (from a clients perspective) a client application is in a “steady state” when ‘it has no pending requests and all of the responses to its current set of requests have been completely received or received to the point where they can be treated as a representation data stream. For a browser application, this state corresponds to a “web page,” including the primary representation and ancillary representations, such as in-line images, embedded applets, and style sheets.’ [1]

    Thus hypermedia as the engine of application state is significant because the application only changes state when a hyperlink is actioned and a new request/response chain starts up again. In the case of HTML this is when a user clicks a link or submits a form, in the case of RDF this is when a machine makes a request on a URI.

    With regards RDFa, I think this hits more on the notion of different kinds of representation, namely RDFa is a “composite media type” as Roy says: “Some media types are intended for automated processing, some are intended to be rendered for viewing by a user, and a few are capable of both. Composite media types can be used to enclose multiple representations in a single message” [2]

    From what I can tell, RDFa has mixed benefits by being a “composite media type”, obviously the amount of data transferred across the wire and processing times are both higher (sometimes significantly); some of this can be offset by proper use of caching and HTTP conditional headers like ETag, If-Match, If-Modified-Since etc.

    This can, and probably should, be compared to utilising the Alternative header, which when done properly offers two distinct routes a client can take depending on whether they are looking for data they can automatically process or data which is to be processed by a human.

    RDFa covers two “grey” areas from what I can tell:
    1: when dealing with search engine robots it allows them to index both machine readable data and human readable data in a single representation.
    2: it eases human developers in to the concept of machine readable data by introducing it in (and as an extension to) an environment which they are used to, namely HTML.

    I think the usage of HTML / RDF / RDFa all comes down to choices made when designing an application and what the intended or likely audience is most likely to be (human/machine).

    As for the specific statement “one very good way to realise HATEOS is indeed RDFa.” – I neither agree nor disagree, certainly it enables HATEOAS, whether it’s any “better” than HTML or RDF all depends on the aforementioned :)

    [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_3_3
    [2] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_2



    Posted by Nathan | 2010-03-07, 13:19

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s



Get every new post delivered to your Inbox.

Join 2,151 other followers

%d bloggers like this: