Friendly url scheme?

Question

One of the many things that's been lacking from my scraper service that I set up last week are pretty URLs. Right now the user parameter is being passed into the script with ?u=, which is a symptom of a lazy hack (which the script admittedly is). However, I've been thinking about redoing it and I'd like to get some feedback on the options available. Right now there are two pages, update and chart, that provide information to the user. Here are the two possibilities that I came up with. "1234" is the user ID number. For technical reasons the user name unfortunately cannot be used:

• http://< tld >/update/1234
• http://< tld >/chart/1234

or

• http://< tld >/1234/update
• http://< tld >/1234/chart

Option #1, conceptually, is calling update with the user ID. Option #2 is providing a verb to operate on a user ID.

From a consistency standpoint, which makes more sense?

---

Another option mentioned is

• http://< tld >/user/1234/update
• http://< tld >/user/1234/chart

This provides room for pages not relating to a specific user. i.e.

• http://< tld >/stats

Answer 1

I personally like this style, because it keeps the user the same, but gives you specific insight in to them.

• http://< tld >/1234/update
• http://< tld >/1234/chart

If you went the other way I would expect to be able to see everything under /update or /chart and then narrow in by user.

Answer 2

Option #1 matches the common ASP.NET MVC examples. Some of the examples at Model View Controller model have the form {controller}/{action}/{id}. The .NET 3.5 quickstart on routing has a table showing some valid route patterns:

Route definition -- Example of matching URL

{controller}/{action}/{id} -- /Products/show/beverages

{table}/Details.aspx -- /Products/Details.aspx

blog/{action}/{entry} -- /blog/show/123

{reporttype}/{year}/{month}/{day} -- /sales/2008/1/5

{locale}/{action}
-- /en-US/show

{language}-{country}/{action}
-- /en-US/show

Answer 3

I agree from a context standpoint, the application followed by the parameters make much more sense to me than the surrogate key for an item followed by the context of what the item is. Ultimately I'd suggest which ever is more natural for you to program.

Answer 4

I'd be gently inclined toward leading with the userid -- option #2 -- since (what exists of) the directory structure is two different functions over a user's data. It's the user's chart, and the user's update.

It's a pretty minor point, though, without knowing if there's plans for significant expansion of the functionality of this thing.

• Is everything going forward going to be additional functions foo and bar and baz for individual users? If so, option #2 gets more attractive for the above reason -- the userid is the core data, it kind of makes sense to start with it semantically.
• Are you going to add non-user-driven functionality? Leading with a header directory might make sense then -- /user/1234/update, /user/1234/chart, /question/45678/activity, /question/45678/stats, etc.

Answer 5

Go with the latter; URLs are meant to be hierarchical (or, at least, users read them that way by analogy to local directory paths). The focus here is on different views of a specific user, so "user" is the more general concept and should appear first.

Answer 6

Convention says object/verb/ID, so it should be:

http://< tld >/user/update/1234

(I just noticed that matches your updated question :)

So yes, #3 is the best choice.

This supports non-user operations as you mention (stats/), as well as multi-user operations:

http://< tld >/user/list/

Answer 7

I just replied to the question "How do you structure your URL routes?" with my opinions about making URLs RESTful, hackable and user friendly. I think it would be better to link than to write something similar in this question, hence the link.

Answer 8

If you go with this scheme it becomes simple to stop (well-behaved) robots from spidering your site:

 http://< tld >/update/1234
 http://< tld >/chart/1234

This is because you could setup a /robots.txt file to contain:

 Disallow /update/
 Disallow /chart/

To me that is a nice bonus which is often overlooked.

Answer 9

If there's a way of listing users I'd introduce a users segment:

http://&lt; tld >/users/ <--- user list
http://&lt; tld >/users/1234/ <--- user profile, use overloaded POST on this to update.
http://&lt; tld >/users/1234/chart/ <--- user chart

If you can only see your own details, ie users are invisible to each other, you don't need the user id since you can infer it from the session, in which case:

http://&lt; tld >/user/ <--- user profile, use overloaded POST on this to update.
http://&lt; tld >/user/chart/ <--- user chart