Tuesday, April 13, 2010

Give it a REST

One point that came up during questions at both recent WSTIERIA talks (at the AIM Programme start-up meeting and the OGC TC meeting) was whether the "authorisation facade" method adopted from the previous SEE-GEO project could properly be said to be applicable to RESTian web services.

In fact, we have been using "REST-style" simply as shorthand for "non-SOAP-based" web services. Although the authorisation facade can easily be seen as a connector component enforcing security policies within a RESTian layered system, its requirement for the presence of an explicit session id in URLs embeds state into those URLs. A particular session id may be valid at a given time but will soon expire, leaving the client with a broken link that cannot be used to access the resource in the longer term.

This isn't a complete show-stopper of course, because many simple web services are accessed by plain HTTP (without SOAP) but don't require the full panoply of REST architectural features. Nevertheless, we should endeavour to be more accurate in the terminology used in future.

Incidentally, this is one reason for being interested in OAuth WRAP (the current specification,, is available in the files area of its Google groups site). WRAP has some conceptual similarities to the SEE-GEO/WSTIERIA method but uses the HTTP Authorization: header to carry a token, exploiting the extensibility built into that part of the HTTP standard, rather than using the URL. Others have used cookies. In either case, the session id or token is taken out of the URL. WRAP additionally provides a mechanism for the client to renew expired tokens. The drawbacks are that, although it has been submitted to IETF for standardisation, WRAP is not yet widely deployed (but implementations are starting to appear, notably from Facebook and Microsoft). The client must also support the protocol. Working with completely unmodified clients, which do not support WRAP (or even cookies) therefore remains one of the strengths of the SEE-GEO/WSTIERIA approach, justifying placement of the session id in the URL.

No comments:

Post a Comment