[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simple aliases for RESTful URLs
On Tue, 24 Feb 2009 22:33:02 +0100, Thomas Jeyaseelan <Thomas.Jeyaseelan@xxxxxxxxxxxxx> wrote:
Hello, I have a question about RESTful URLs. These URLs point to ATOM
entries or feeds.
Small nit to begin with: Atom isn't an abbreviation, so there's really no reason to write it in uppercase. :)
Our service defines URLs to our resources in the following manner:
What an exotic URI space. What's the theory behind having the different nouns look like method calls with the ID as an argument? Is this actually transformed in some way to an underlying method by the same name or does the syntax make sense in some other way?
Whatever your intentions with this is, I have to say that on the surface, it looks a lot like RPC calls. Why not use the following less exotic URIs instead:
For this reason, we'd like to consider having a URL:
As an alternative URI, I'd consider:
If the data type of a blog's ID is integer, you can easilly distinguish "default" from the ID. Either way, you'd most probably not have a bazillion different defined keywords like "default" and can pretty much just hard-code it right in, I guess.
...where "DefaultBlog" is simply a special keyword that indicates to the
server to locate the default blog in the blogs collection. In our case,
this will locate the only blog owned by the user (since a user can have
at most one blog in our application right now).
Now, however, we have two URLs pointing to the same resource; the blog
that's considered the default.
Should one URL redirect to the other?
.../Blogs('default')/... redirect to .../Blogs('1234XYZ')/... ? Is there
a standard, or recommended way to do this?
You should always redirect to the most canonical URI for a given entity. Therefore, the "default" URI should redirect to the URI with the ID in it. The reasoning here can be that you might want to be using the "default" keyword to mean something different in the future, where a user might have several blogs but still prefers to make one of them her default blog.
I see pros and cons with both approaches: Having two separate URLs
indicates two different resources; it's not obvious that the URLs point
to the same resource. Having one URL with the second redirecting, on the
other hand, creates headaches for the client, because it will have to
handle redirects for every REST operation on the client. One solution to
alleviate this would be to always use the alias ('default') as the key
for the default item, and hide the "real" numerical key, so that the
numerical version returns a 404. This creates some ambiguity, too,
Redirects can be handled pretty much automatically by most HTTP libraries these days, so I don't see the big headache. The performance hit will be minimal too. If there is headaches involved, however, you could just do a permanent redirect with "301 Moved Permanently". As the HTTP specification says:
Clients with link editing capabilities ought to automatically
re-link references to the Request-URI to one or more of the
new references returned by the server, where possible. This
response is cacheable unless indicated otherwise.
In other words; the client should not resubmit future requests to the "default" URI, but should instead hammer the canonical URI with the ID in it. Unless it's very important to keep the "default" URI for all requests, I'd say this is the way to go.
Asbjørn Ulsberg -=|=- asbjorn@xxxxxxxxxx
«He's a loathsome offensive brute, yet I can't look away»