Comments on: RESTful URIs

By: DamnHandy » RESTful URIs, Unicorns, and Pixie Dust

DamnHandy » RESTful URIs, Unicorns, and Pixie Dust — Thu, 29 Dec 2011 15:34:10 +0000

[...] some questionable advice as to what constitutes a “RESTful URL.” Subbu has another nice post dispelling some of those claims, so I won’t get into it here. The problem with doing all of [...]

By: On Linking - Part 1 at subbu.org

On Linking - Part 1 at subbu.org — Sun, 28 Sep 2008 08:57:31 +0000

[...] Interop?Resource Access SpinQuick Comment on "Tunnel as deployed"Another REST Anti-PatternRESTful URIsAvoid Versioning – PleaseHypermedia ClientsContent Negotiation is not BrokenHypermedia and [...]

By: Mark Nottingham

Mark Nottingham — Mon, 04 Aug 2008 03:33:12 +0000

There are a few differences, mostly minor.

If you don’t set explicit freshness information (Expires or Cache-Control), a cache will treat a response with a query parameter as uncacheable.

In theory, this should only happen when the origin server is HTTP/1.0; in practice, it happens for 1.1 servers as well, because Via isn’t well-implemented, and caches need to be conservative.

Many existing cache deployments will consider all URLs with query parameters to be uncacheable, period.

The other practical difference is that URIs with query parameters doen’t work as well as relative references. Sometimes a minor optimisation, but sometimes important (especially when you’re trying to convince someone that using URIs as identifiers doesn’t add a lot of overhead).

There’s also a (very soft) human perception impact; people tend to think that things with query parameters may change, based upon their previous experience. Only an issue if people will see your URI…

By: Remmrit Bookmarking

Remmrit Bookmarking — Mon, 21 Jul 2008 13:00:57 +0000

Bookmarks

Remmrit.com user has just tagged your post as !

By: Subbu Allamaraju

Subbu Allamaraju — Fri, 11 Jul 2008 15:39:03 +0000

The litmus test that Aristotle was referring to is to use different URIs for different operations. I don’t think the issue was query parameters per se. At least that’s how I read his comment.

I don’t think rewrite rules are redundant or can go away since there is a lot of software that can only deal with query parameters.

By: Bill de hOra

Bill de hOra — Fri, 11 Jul 2008 14:34:48 +0000

“I agree. That’s a good litmus test.”

Of course it is. And that was the point of the “argument” you refer to, but failed to quote – if you avoid query params such problems, including redundant rewrite rules, go away. It’s not just a matter of taste.

By: Subbu Allamaraju

Subbu Allamaraju — Fri, 11 Jul 2008 05:54:48 +0000

I agree. That’s a good litmus test.

By: Aristotle Pagaltzis

Aristotle Pagaltzis — Fri, 11 Jul 2008 03:08:31 +0000

What I mean is that if you update http://mystore.com/product?id=1245 by POSTing to http://mystore.com/admin/details?id=1245 then you are really using URIs to identify methods, not resources, which you identify instead by using an app-private identifier (a numeric ID in this case) passed as a parameter in the query string. This is the CGI style and is a REST-RPC hybrid rather than a RESTful system: the resource is subordinate to the actions that operate on it.

By: Peter Thomas

Peter Thomas — Thu, 10 Jul 2008 21:29:13 +0000

I agree that choosing one or the other is more a matter of personal taste. But IMHO the so-called "REST-ful" URLs start to make sense for nested structures. For example: http://mystore.com/customer/5/order/8 instead of http://mystore.com/view?customerId=5&orderId=8

By: Subbu Allamaraju

Subbu Allamaraju — Thu, 10 Jul 2008 19:23:03 +0000

That's the approach we started with at work, but does it really matter? If the server says that http://mystore.com/product?id=1245 identifies a resource, and an OPTIONS request to that URI returns PUT and DELETE, so be it.