REST

URI Templates and REST URL Matching

OK, so I haven't posted in a long time. Figure I'll ease in with an issue that I wanted to write about a while back. Oh yeah, and I turned off comments because the spam was out of control :)

For those watching the REST space, I'm sure Joe Gregorio's work on the IETF URI templates draft is interesting. The initial draft (draft-gregorio-uritemplate-01.txt) took a simple approach to describe URIs with variable parts. The idea was that parameterized variable parts would have { var name } within the URI to indicate the variable parts. A simple example would look like this:

http://foo.com/accounts/{accountID}

where the account ID could be substituted with an appropriate ID in an instance of the REST URI:

http://foo.com/accounts/9991234

This approach was simple enough. It could be used in a straightforward manner when calling a REST service by substituting the variables parts with values prior to the invocation. It could also be used somewhat for matching inbound requests by transforming the template into a regular expression, replacing the variables with non-greedy matches.

In the process of updating the template specification, and despite many questions about matching inbound requests on the mailing list, Joe Gregorio stated that he never intended for URI templates to be used for matching but only for substitution. Indeed, the next version of the specification (draft-gregorio-uritemplate-02.txt introduced a bunch of new operators aimed at the substitution. The primary use cases that Mr. Gregario was interested in solving where client-side: simplifying the process of making a RESTful request from a JSP input form, for example, which would substitue the input form variables into their respective places in the REST request.

Syndicate content