Every time I step out side my cubby hole to find out what people are saying about REST, I come
across some geek (sorry – this is hearsay and hence no references) making a pitch that
includes the following:
- URIs with query parameters are not good
- Servers that don’t map every path segment of a URI to a sub-resource in a resource tree are not RESTful
These are misleading, and the numbers of developers that “believe” in these seems to be growing given that no one in the audience questioned (I was told) about these assertions when they were presented.
The first of these perceptions is partly based on what Sec 13.9 of RFC 2616 says about "Side Effects of GET and HEAD"
We note one exception to this rule: since some applications have
traditionally used GETs and HEADs with query URLs (those containing a
"?" in the rel_path part) to perform operations with significant side
effects, caches MUST NOT treat responses to such URIs as fresh unless
the server provides an explicit expiration time. This specifically
means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
be taken from a cache.
This implies that, if you add caching headers (such as Cache-Control, Last-Modified etc.), the response should be cacheable even if the URI has a query string. However, as discussed in
How cachable is google (part 1): Google Maps, for historical reasons, caches like Squid treat those responses as uncacheable despite the caching headers. But there is simple way to configure Squid to not ignore such URIs.
acl QUERY urlpath_regex cgi-bin ? cache allow QUERY
This will still leave responses bypassing intermediate caches that don't understand HTTP 1.1 or are configured to ignore such URIs from being cached, but you can at least front end the web server with a cache. In my limited testing with browsers, I found that browsers do cache responses from URIs that have query strings.
The second of the perceptions is a pure myth. See RESTful URIs. Instead of focusing on URI syntax, think about linking.
{ 1 comment… read it below or add one }
In around Squid 2.7STABLE1, the default changed to allow caching of queries; however, as per the RFC those responses need to have explicit freshness associated with them (i.e., an Expires or Cache-Control: max-age).