dretblog

REST Layers and REST Applications

there has been a rather long history of people trying to describe REST applications, and an equally long history of responses saying that it cannot be done, should not be done, and that REST is allow about following your nose across a web of interlinked resources. many approaches have used some kind of RDF-based model, and have either tried to model/describe an application in terms of SemWeb principles, or in some cases the standards (such as HTTP) themselves. however, so far there seems to be no consensus on whether it could/should be done, and given the fact that we expect RESTful APIs to become more popular, it would be good if the REST community could provide some guidance on how those APIs should be described/documented.

in an attempt to better understand what and why people are trying to accomplish when they try to describe REST, here is a first approach to more cleanly layer the issues, see what's already around, and try to figure out what value could provided by some format/technology for each layer. we are actively working in this area because we simply need something that will allow service providers to describe (and by that we mostly mean document) their services. our platform allow customers to define and expose REST services, and when they do this and want to point, for example, external partners at these services asking them to develop clients, instructing them to tell your external partners to follow their nose just doesn't quite cut it.

in this first attempt at a layering model, there are five layers:

1. architectural style: this is where REST itself is defined, independent of any technology. this is where the architectural principles of the style are defined, and fielding' thesis by definition is the one and only authoritative source in this layer.
2. technology framework: on top of REST's principles, web architecture encompasses a set of enabling mechanisms, most importantly URI for identification, HTTP for interaction, and media types for labeling representations (and it is interesting to notice that the core technologies on this layer are all defined by IETF instead of the W3C). while this layer is essential for the fabric of the web, in itself it does not yet define a working system, because it lacks concrete representations that can be used as transfer formats.
3. core technologies: for the human web, HTML is the most important media type (but without more media types such as images, the web never have succeeded), and for machines XML and RDF have become important enabling technologies. it is important to notice that all of these media type are application-agnostic and not application-specific formats. clients need to support those media types to work properly, but without additional guidance (provided by human operators or additional information), they don't know what they are doing and blindly interact with a set of semantically shallow resources. core technologies allow clients to work in a RESTful way, but they may not allow servers to expose the richness of the services they are providing.
4. added semantics: (almost) all of the web's core technologies have some mechanism to add semantics. sometimes these mechanisms have formalized representations (such as XML's DTDs or XSD), sometimes not (HTML profiles are not described in any standardized way). some added semantics are metamodels (XML schema languages allow authors to define their own schemas), some are fixed models (podcasts define a fixed set of extensions that can be found in feeds). most importantly, the core technologies provide ways how these added semantics can be signaled to clients, for XML through namespaces and/or associated schemas, and for HTML through profile parameters (and the proposed 'profile' link relation type might be able to unify this mechanism across media types). added semantics allow servers and clients to support semantic overlays that allow richer and more semantics-driven forms of interaction.
5. applications: based on core technologies and possibly added semantics, developers build applications, which expose the resources of a given service in some URI space. these applications can use any number of media types and any set of added semantics on top of these, and in some cases developers will define their own media types, whereas in others they will just reuse existing ones. in both cases, the application is seamlessly embedded into the bigger context of the RESTful system, and while that may be not interesting at all for some clients, and might as well be interesting for others. for the HTML web, google's sitemaps format has become an established representation in this area because it allows servers and certain clients (crawlers) to interact in ways that are advantageous for both sides.

based on some of the discussions that happened around describing REST, it seems that at times, there was a mismatch in where in these layers people wanted to be. when it comes to layers 3 and 4, documentation/description should be the media type or semantic extension itself. for these cases, all that a client should need to know is the processing and operational model of the resource, and then it can act. however, when it comes to layer 5, i am a firm believer that there are scenarios where a description format would be very desirable, and the sitemaps format is one (very widely deployed) example.

in our work on the Resource Linking Language (ReLL) we have explored this area and made some design choices that i would now make differently. but generally speaking, giving application providers the possibility to describe the extent of their application and doing that in a way which itself is a self-describing resource seems like a very RESTful approach. if a client is interested in this information, there is a discovery mechanism (for sitemaps a slightly awkward robots.txt-based rule that hardcodes an URI-based approach) and then the client can happily use that information, and could for example inform the user that he is now leaving the application (which may or may not be indicated by a change in the some URI prefix). if clients are not interested in the notion of an application at all (like regular users happily surfing the web without ever experiencing application boundaries), they simply ignore this information.

starting from this idea of REST layers, i'd be curious to get some feedback about the perceived usefulness of a description language that specifically just resides in layer 5. the main goal is to establish a format that could be seen as sitemaps for REST, and definitely should be less chatty than exhaustively listing all URIs. this would allow service providers to describe the universe of resources they are exposing, and would give clients a snapshot view of the current expectations they can have about exposed resources, and the assumptions about where the scope of the applications ends. in a follow-up to this post, i will outline our scenarios, and write more about the things we would like to include and exclude in such a REST Application Description Language.

Resource Profiles

one of the not-so-well-known features of HTML is the ability to specify a profile attribute for a web page. it goes right in the head element like this: <head profile=" some URI ">. here is what the HTML spec says about this attribute:

This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.

The profile attribute of the HEAD specifies the location of a meta data profile. The value of the profile attribute is a URI. User agents may use this URI in two ways:

• As a globally unique name. User agents may be able to recognize the name (without actually retrieving the profile) and perform some activity based on known conventions for that profile. For instance, search engines could provide an interface for searching through catalogs of HTML documents, where these documents all use the same profile for representing catalog entries.
• As a link. User agents may dereference the URI and perform some activity based on the actual definitions within the profile (e.g., authorize the usage of the profile within the current HTML document). This specification does not define formats for profiles.

the HTML profile attribute is defined so that it may contain white-space separated URIs, each of them identifying one profile. this is a bit unconventional, but the overall design goal is clear and reasonable: why restrict a web page to only conform to one profile? in practice, though, the profile attribute is hardly ever used, and if people know of any deployments where it is actually being used by clients, please make sure to point to this in a comment!

in our work on RESTful services, we have repeatedly run into the situation where we want to have a runtime mechanism how a resource can represent the fact that it follows additional constraints and/or rules. creating media types at runtime is not such a great idea, and it would also not allow us to represent the fact that a resource is still using a representation based on some media type, but also can be treated according to additional constraints and/or rules. a profile mechanism would be a good way of doing this, and thus we would like it to become a recognized link relation type.

seeing that profiles are a good idea, but should not be restricted to HTML and thus be represented in a more generic way, microformats.org published a proposal for a profile relation type a while ago. this is a good initiative, but there are two downsides to the current microformat proposal:

• it is not intended to register the profile link relation type in the IANA link relation type registry as defined by RFC5988. it would be useful to have this link relation type standardized at the web level.
• the proposal makes assumptions about the linked resources and the processing model for them. instead, it should be left to media types (the ones using/supporting profiles and possibly profile media types themselves) to makes these assumptions, so that the link relation is decoupled from media type specifics.

this means that it might be a good idea to push forward with an I-D proposal to standardize a profile link relation type. This relation type would state that such a link serves as an identifier that a resource representation follows additional constraints or rules, so that clients processing it could take those into account. whether the link is dereferencable at all and if so, what kind of resource it would point to, would be left open. this blog post is soliciting feedback about this idea, and any yes, this would be a good idea, please make it happen! or no, this is a bad idea and here is why comment is welcome. depending on the feedback, i'll continue with my work to publish an initial draft, which should be out in the next week or two.

[[ update 2012-04-15: there now is a draft out, draft-wilde-profile-link is available through the IETF site (and the IETF datatracker), and as of today has been updated to version 01. ]]

Action URIs

anybody doing non-trivial things with REST sooner or later runs into interactions beyond the simple CRUD (create/read/update/delete) operations. there often are cases where operations might be tied to a specific resource (or mainly to that resource), and then the question is how model this in a RESTful way. a pattern that is seen frequently is the action URI, which is a URI that specifically represents one action on one resource.

for example, if there is an open order http://example.com/order/42, then the payment action will be represented at the URI http://example.com/order/42/payment. clients will interact with that by using either PUT or POST (PUT seems to be the preferred way) to submit a payment.

this clearly works, as demonstrated by many existing APIs, but is it really the best or only way of doing it? there are some issues with this design:

1. no linking: if this is just a payment service, why not use http://example.com/order/payment instead and have a payment media type that links to the order being paid? that would not only make the payment resource a more reasonable interaction point (it's basically like a cashier accepting many different things to be paid for), it also would allow for richer functionality such as paying for multiple orders (simply link to all the orders you're paying for) or even paying for third-party orders (simply link to these 3rd-party orders).
2. contrived resource model: if the action indeed is bound to a single resource (in contrast to the potentially more general action mentioned in issue 1), then why is it a resource? it seems that the interaction taking place is to submit a state change to the actual resource, and then that resource is changing state (from awaiting payment to paid) as a result of that interaction. what is the reasoning behind turning the payment into an action, and why is it significantly better than the dreaded just embed action=payment in URI query parameters anti-pattern?
3. not media type centric: if payment is done using a payment request, then there has to be a self-describing document conveying the payment data. this could be submitted to a general payment resource (as described in issue 1) or to the resource itself (as described in issue 2), but there really does not seem to be a good reason why it would need to be submitted to a specific URI just minted for that particular operation on that particular resource.

please keep in mind that even if you would use a general-purpose payment URI or POST a payment to the order URI, clients would still only be linked to the payment URI when payment would be a state change permitted by the server. as usual, a rel="payment" link would only be included if paying was an option, and the only difference to the resource-specific action URI approach would be that it would point to either a general-purpose payment URI, or to the URI of the order accepting the payment media type.

after a quick but non-representative look at some books and APIs, it seems to me that the resource-specific action URI is a pretty common pattern, and i would be interested in opinions about the alternatives, and also whether people have looked at all these patterns and have made decisions between them because of constraints that made one pattern a better fit that the other. as usual, there are many ways to solve a given problem, but the resource-specific action URI may be one pattern that could be replaced by others, at least in some scenarios.

Creating Resources with GET/PUT

creating resources the RESTful way can be done with either PUT or POST, with PUT expecting that the URI of the created resource is known in advance (by the client issuing the request). semantically, the difference is that PUT is idempotent and thus can be repeated safely, whereas POST is non-idempotent and thus cannot be repeated. a PUT can be repeated because after creating a resource, a repeated PUT will simply overwrite the resource with the same representation, whereas a POST always is directed towards some factory resource, and thus repeating it would create a duplicate, which should be avoided.

in many cases, clients do not know the URI of the new resource, so the PUT approach cannot be used. the problem with the simple POST model is that clients have a hard time figuring out what to do when the POST request fails (e.g., the HTTP library says something went wrong). did the request make it to the server and cause a resource to be created? or did the request fail before that and the client could retry the POST? HTTP semantics say that POSTs cannot be repeated, so what now?

this is where people came up with the POST/PUT pattern. clients POST to a factory resource, but mostly in an attempt to get the URI of a new resource. a often useful side-effect of this pattern is that the server can return a template for the resource, allowing a client to understand what is expected. after the client has received the URI of the new resource, it PUTs the actual data there, and the important observation is that this PUT request can be safely repeated if it fails, because of its HTTP semantics.

what this does is simply push complexity around. instead of having to deal with possible duplicates being created, the server now has to deal with possible templates that were never populated. in many scenarios, this latter task is easier to do that the former one, it's essentially garbage collection and the server can clean up all resources that were created as a result of a POST, but were never populated with a subsequent PUT. if a client waits for an absurdly long period of time and then attempts to PUT to a resource that was garbage-collected, then it's up to server logic to either keep track of all URIs ever minted (which might get expensive), or just use URIs that are very unlikely to collide. in either case, the server would let the client know that the URI is gone, and that a new one should be requested by POSTing to the factory.

so far, this is just what people have been doing for a while already. as a new twist, what if the creation of a resource on the server is actually a fairly heavy-weight operation, because of all sorts of bookkeeping and retention mechanisms built into the persistence layer? creating a resource before it has been populated ideally should be avoided, because garbage collection is not as easy; as soon as a resource has been created, a lot of repository data is being created and cannot be deleted anymore.

the question i have been very slowly getting to thus is the following: in such a scenario, what about issuing a one-time token as a result of an initial request, which allows the client to PUT to that URI. but only if that PUT happens, the actual resource will be created in the repository. the token is just a place-holder, and the URI of the actual resource depends on the creation of the repository-level URI. in that case, the first PUT will be accepted, but will result in a 303 response that redirects to the cool URI. a second request to the token URI should result in a redirect as well, so that clients know that this token has been used.

there are two ways how the tokens can be associated with the cool URIs. the REST layer could maintain a list of token/persistent URI pairs, or the repository itself could have a field for each resource that keeps track of the token from which a resource has been generated. fast look-up is important, but can be done in either case. extending the repository model probably is the better way to go, but may not be possible in all cases. it is important to notice that tokens only need to be tracked once they have been used (i.e., something has been PUT there), before that, all that is needed is a token scheme that makes collisions highly unlikely (such as time stamp + client IP + random string).

here is the proposed sequence of steps in this scenario:

1. clients GET the template and a token from the factory resource. since this operation does not change server state, it is safe and idempotent and it is possible to use GET.
2. clients PUT to the token URI, at which point the server creates and populates the resource at the repository level, and keeps track of the token from which the resource has been created. the server responds with a 303 (See Other) response, indicating the persistent URI of the resource.
3. subsequent requests to the token URIs are handled with a 301 (Moved Permanently) response, telling clients that the token URI should no longer be used, and that a persistent URI is now available.

if the initial GET fails, it can be repeated safely, because it does not change server state, and thus is safe and idempotent. if something goes wrong with the PUT, it can be repeated, but if the server receives a repeated request, it will redirected with a 301. as soon as the resource has been created and the persistent URI is established, future interactions with the resource work as usual.

what are the main benefits of this approach?

• the factory GET allows the server to supply a template, and tell the client where to direct requests for creation. since the server is providing the URI, we can use PUT requests for creating the resource at this known URI. this initial step is stateless on the server side.
• the token-based creation allows the server to delay persistence-layer creation until something has been PUT by the client. the tokens are one-time PUT only, and after that they respond with 301. this approach scales with the number of resources, not with the number of clients, and usually is simply one more attribute in the persistence layer.

any feedback on this pattern is very welcome. has it been used somewhere else? does it seem to introduce problems not discussed here? is there a simpler way of handling the same scenario?

Atom Content Negotiation

media types are an important part of web architecture, and they even have (some) structure; the very obvious type/subtype syntax, and the maybe not as obvious "+" convention in types such as application/atom+xml. however, while that allows you to expose the fact that something is Atom and that Atom is based on XML, it does not allow you to talk about what the published entries are.

let's assume you have a collection of items that is exposed via feeds and managed in whatever back-end storage works well for you. you want to be a good web citizen and publish it as HTML, XML, JSON, and RDF. you also want to be a good web service citizen and publish any updates via feeds, so that consumers are notified whenever the collection changes. what is the best web pattern to do that? currently, there are two main approaches:

• publish different feeds. in this case, each content type is published in a different feed. one problem is that these feeds are not interlinked, so it is not possible to switch feeds easily. another problem is that there is no way how to advertise these feeds in a way that marks them as being content type variants of the same content.
• link content variants. in our suggestions for Web Services for Recovery.gov, we had just one feed that would embed reports in HTML, and an XML version would be linked in each entry as an alternate version. this clearly makes HTML primary and XML secondary, and if all you're interested in is XML, it forces you to GET all HTML, only to ignore it and then GET the XML.

both approaches have advantages and disadvantages, and both are not very pretty. in addition, when adding more advanced feed-based services such as updates and push, well-defined handling of content types across the whole landscape becomes more important.

i am wondering what the more popular approach is, and why. i am also wondering whether it might be worth the effort to have a small extension that would make this more reliable in the sense that there would be a link relation for interlinking feeds that carry the same content, but using different content types. it could be as simple as having such a link on the feed level:

<link rel="alternate-content" href="..." content-type="application/xml"/>

is that something that would be worth doing? it could become more sophisticated (and complicated) by allowing other feed parameters to be negotiated, such as feed formats (here's an RSS version of me), feed variants (here is the feed with breaking news only, here's the feed with abstracts only), and probably a variety of other things. currently, i would be tempted to do the simple version only, but i am really curious to find out in which cases these problems already have been solved, in which way they have been solved, and whether standardizing this might provide some value.

[[ a pointer to this entry has been posted to the atom-syntax mailing list. ]]

WoT 2011 Deadline Extended

due to popular demand, we have decided to extend the submission deadline for the Second International Workshop on the Web of Things (WoT 2011). The new dates are shown below in the excerpt from the original Call for Papers for WoT 2011 (which has also been updated).

Important Dates

• Submission deadline: February 11, 2011
• Notification of acceptance: March 11, 2011
• Camera-ready versions of accepted papers: March 21, 2011
• WoT 2011 Workshop: June 12, 2011

we are looking forward to your submissions! please refer to the submission instructions for preparing your submission and submit papers at the WoT 2011 EasyChair submission page (thanks again EasyChair for the great free service!).

WS-REST 2011 Deadline Extended

due to popular demand, we have decided to extend the submission deadline for the Second International Workshop on RESTful Design (WS-REST 2011). The changed dates are shown below in the excerpt from the original Call for Papers for WS-REST 2011 (which has also been updated).

Important Dates

• Submission deadline: January 31 February 10, 2011, 23.59 local time San Francisco, CA (PST)
• Notification of acceptance: February 15 25, 2011
• Camera-ready versions of accepted papers: February 28 March 12, 2011
• WS-REST 2011 Workshop: March 28, 2011

we are looking forward to your submissions! please refer to the submission instructions for preparing your submission and submit papers at the WS-REST 2011 EasyChair submission page (thanks again EasyChair for the great free service!).

Workshop on RESTful Design 2011 (WS-REST 2011): Call for Papers

Second International Workshop on RESTful Design (WS-REST 2011)

In conjunction with the Twentieth International World Wide Web Conference (WWW2011), Hyderabad, India

The Second International Workshop on RESTful Design (WS-REST 2011) aims to provide a forum for discussion and dissemination of research on the emerging resource-oriented style of Web service design.

Background

Over the past few years, several discussions between advocates of the two major architectural styles for designing and implementing Web services (the RPC/ESB-oriented approach and the resource-oriented approach) have been mainly held outside of the research and academic community, within dedicated mailing lists, forums and practitioner communities. The RESTful approach to Web services has also received a significant amount of attention from industry as indicated by the numerous technical books being published on the topic.

This second edition of WS-REST, co-located with the WWW2011 conference, aims at providing an academic forum for discussing current emerging research topics centered around the application of REST, as well as advanced application scenarios for building large scale distributed systems.

In addition to presentations on novel applications of RESTful Web services technologies, the workshop program will also include discussions on the limits of the applicability of the REST architectural style, as well as recent advances in research that aim at tackling new problems that may require to extend the basic REST architectural style. The organizers are seeking novel and original, high quality paper submissions on research contributions focusing on the following topics:

• Applications of the REST architectural style to novel domains
• Design Patterns and Anti-Patterns for RESTful services
• RESTful service composition
• Inverted REST (REST for push events)
• Integration of Pub/Sub with REST
• Performance and QoS Evaluations of RESTful services
• REST compliant transaction models
• Mashups
• Frameworks and toolkits for RESTful service implementations
• Frameworks and toolkits for RESTful service consumption
• Modeling RESTful services
• Resource Design and Granularity
• Evolution of RESTful services
• Versioning and Extension of REST APIs
• HTTP extensions and replacements
• REST compliant protocols beyond HTTP
• Multi-Protocol REST (REST architectures across protocols)

All workshop papers are peer-reviewed and accepted papers will be published as part of the ACM Digital Library. Two kinds of contributions are sought: short position papers (not to exceed 4 pages in ACM style format) describing particular challenges or experiences relevant to the scope of the workshop, and full research papers (not to exceed 8 pages in the ACM style format) describing novel solutions to relevant problems. Technology demonstrations are particularly welcome, and we encourage authors to focus on lessons learned rather than describing an implementation.

Papers must be submitted electronically in PDF format.

Easychair submission page: http://www.easychair.org/conferences/?conf=wsrest2011

Important Dates

• Submission deadline: January 31 February 10, 2011, 23.59 local time San Francisco, CA (PST)
• Notification of acceptance: February 15 25, 2011
• Camera-ready versions of accepted papers: February 28 March 12, 2011
• WS-REST 2011 Workshop: March 28, 2011

Organizers

• Cesare Pautasso, Faculty of Informatics, USI Lugano, Switzerland
• Erik Wilde, School of Information, UC Berkeley, USA
• Rosa Alarcon, Computer Science Department, Pontificia Universidad de Chile, Chile

Program Committee

• Jan Algermissen, Nord Software Consulting, Germany
• Subbu Allamaraju, Yahoo Inc., USA
• Mike Amudsen, USA
• Benjamin Carlyle, Australia
• Stuart Charlton, Elastra, USA
• Duncan Cragg, USA
• Joe Gregorio, Google, USA
• Michael Hausenblas, DERI, Ireland
• Ralph Johnson, University of Illinois, USA
• Rohit Khare, 4K Associates, USA
• Yves Lafon, W3C, USA
• Frank Leymann, University of Stuttgart, Germany
• Ian Robinson, Thoughtworks, UK
• Stefan Tilkov, innoQ, Germany
• Steve Vinoski, Verivue, USA
• Jim Webber, NEO4J
• Olaf Zimmermann, IBM Zurich Research Lab, Switzerland

Contact

WS-REST 2011 Web site: http://ws-rest.org/2011/
WS-REST 2011 Twitter: http://twitter.com/wsrest2011
WS-REST 2011 Email: chairs@ws-rest.org

Web of Things 2011 (WoT 2011): Call for Papers

Second International Workshop on the Web of Things (WoT 2011)

In conjunction with the Ninth International Conference on Pervasive Computing (Pervasive 2011), San Francisco, California

Web site: http://www.webofthings.com/wot/2011/

Paper submission deadline: February 4, 2011
Notification of acceptance: March 11, 2011
Camera-ready papers due: March 21, 2011
Workshop Date: June 12, 2011

The world of embedded devices has experienced radical changes; real-world objects such as home appliances, industrial machines and wireless sensor and actuator networks embed powerful computers which often can connect to the Internet. Likewise, more and more common objects are being tagged with RFID tags or barcodes. Considering the recent progress in mobile communications (increased bandwidth for cell phone networks, as well as urban wireless broadband networks), Internet access will very likely become a commodity accessible from most real-world devices. This convergence of physical computing devices (wireless sensor networks, mobile phones, embedded computers, etc.) and the Internet provides new design opportunities and challenges, as digital communication networks will increasingly not only serve virtual data (images, text, etc.), but also serve access to real objects. While the Internet of Things has become a well-known brand for a set of research issues in the pervasive and ubiquitous computing communities, the main focus of this research theme has been on establishing connectivity in a variety of challenging and constrained networking environments. Our hypothesis is that the Web of Things is the next logical step in the ongoing evolution, enabling new applications and providing new opportunities. The Web of Things takes the next step from establishing connectivity and thus the ability to communicate with Things, to a vision where Things become seamlessly integrated into the Web, not just through Web-based user interfaces of specific applications, but by simply blending into the information and interaction space created by the Web and its architectural principles. The Web of Things workshop solicits contributions in the areas of architectures for a Web of things, decentralization, real-time interactions with things, services for the physical world, Web-scale applications, as well as questions of user interface and interaction design, where a Web of Things requires application designers to think beyond standard Web browsers and embrace alternative clients such as mobile devices or even more constrained environments.

• Decentralized Web architectures fostering the Web of Things
• Real-time communication with the real-world
• Deployments, and evaluation of Web of things systems
• Human-things interaction models and paradigms
• Web composition of the physical world and physical mashups
• Searching and discovering things and their services on the Web
• Security, access control, sharing of physical things on the Web
• Applications of the Web of Things (smart homes/cities/factories)
• Business opportunities for the Web of Things
• Use and developments of latest Web technologies for the physical world (e.g., 6lowpan, HTML5, microformats, REST, cloud and services, social networks, etc.)

In this second edition of the workshop (WoT 2010 took place at PerCom 2010) will will consolidate the community and focus even more on the Web aspect of networking things. We will provide an interactive forum for WoT researchers to learn and discuss about existing efforts to enable cross-fertilization. In order to ensure a high-quality technical session, submissions must cover one of the topics above and should not exceed six (6) ACM SIG Proceedings Template pages. Research papers must be original prior unpublished work and not under review elsewhere as they will be published to the ACM digital library and listed on DBLP. All submissions will be peer-reviewed and selected based on their originality, merit, and relevance to the workshop. Submission requires at least one author to present the paper on-site.

Organizers:

• Dominique Guinard, ETH Zurich and SAP Research Zurich
• Erik Wilde, School of Information, UC Berkeley
• Vlad Trifa, ETH Zurich and SAP Research Zurich

Program Committee:

• Friedemann Mattern, ETH Zurich, Switzerland
• Albrecht Schmidt, University of Duisburg Essen, Germany
• Cesare Pautasso, Universita della Svizzera Italiana (USI), Switzerland
• Adam Dunkels, SICS, Sweden
• Vlad Stirbu, NOKIA, Finland
• Gary Gale, Nokia, Germany
• David Resseguie, Oak Ridge National Laboratory, USA
• Marc Langheinrich, Universita della Svizzera Italiana (USI), Switzerland
• Rosa Alarcon, Pontificia Universidad Catolica, Chile
• Tim Kindberg, matter 2 media, UK
• Florian Michahelles, ETH Zurich, Switzerland
• Inaki Vazquez, University of Deusto, Spain
• Gerd Kortuem, Lancaster University, UK
• Dave Raggett, W3C, UK
• Olivier Liechti, University of Applied Sciences of Western Switzerland, Switzerland
• Christian Floerkemeier, Auto-ID Labs, MIT, USA
• Artem Katasonov, VTT Labs, Finland
• Liselott Brunnberg, MIT Mobile Experience Lab, USA
• Guido Moritz, University of Rostock, Germany
• Claro Noda, Universidade do Minho, Portugal
• Masayuki Iwai, University of Toyko, Japan
• Jacques Pasquier, University of Fribourg, Switzerland
• Till Riedel, TecO Karlsruhe Institute of Technology, Germany
• Rodger Lea, University of British Columbia, Canada

Web Linking

one of the main components of REST is linking (modeling applications as hypermedia, i.e. interconnected resources), and more specifically, typed linking, where a link not only specifies where it links to (in web-oriented systems this is always done using URIs), but what it links to, so that clients can choose which links to follow. in many cases, these link types are application-specific, but there also are link types which are fairly universal, and which should be reused across applications instead of being reinvented many times.

so far, link relation types were defined within the confines of applications and/or representations; both HTML and Atom/AtomPub, for example, define their own link relation types, and those are only expected to be used for these specific representation types.

the recently published RFC 5988 (Web Linking) specifies relation types for web links more generally, and defines a registry for them. it also defines the use of such links in HTTP headers using the Link header field. this means that from now on, links for RESTful application do not (necessarily) have to be embedded in representations anymore. instead, if they pertain to the requested resource, they can be communicated in a Link header field, which is specifically mentioned to be semantically equivalent to HTML's <link> element and Atom's feed-level <link> element.

the immediate advantage of this approach is that links can now be used for resources where the representation does not define a place to put them, and that resources do not have to be parsed to find links connecting them to other resources. in fact, by using HEAD requests, resources do not even have to be retrieved to find the links that link them to other resources, which means that Link-aware clients can traverse RESTful services in a much more efficient way, as long as all they need are resource-level links.

adding to my REST Programming Toolbox Requirements, i would thus expect a good REST programming toolbox to start supporting the Link header field, and to allow applications to more or less ignore the fact whether a link has been found in resource, or in a Link header field. ideally, a toolbox might even be smart enough to optimize requests, so that HEAD requests are used whenever only resource-level links are required in cases where the server supports the Link header field. this, however, requires knowledge of whether the server will reliably serialize all links as Link header fields, and this is not something that can be determined automatically; a programmer would have to configure that.

in addition to the initial link types defined by RFC 5988, RFCs 5829 (Link Relation Types for Simple Version Navigation between Web Resources) and 5989 (A SIP Event Package for Subscribing to Changes to an HTTP Resource) have added values to the registry so far, and over time the registry should grow as a place where RESTful applications can look up, reuse, and add link relation types for hypermedia-driven applications.

since RFC 5988 extends the way in which link types should be handled in Atom and can be exposed by HTTP servers publishing Atom, i have restructured the Atom Landscape Overview to start listing any RFCs (or drafts) that might add link relation types to the link relation type registry. as usual, any feedback to further improve the overview is greatly appreciated.