Friendly URL scheme?

Question

One of the many things that were missing from my scaper service that I installed last week is pretty URLs. Right now, the user parameter is being passed to the script with? U =, which is a sign of lazy hacking (which, admittedly, is a script). However, I was thinking about reusing it, and I would like to get some feedback on the options available. Now there are two pages, an update and a diagram, which provide information to the user. Here are two possibilities I came up with. "1234" is the user identification number. For technical reasons, the username, unfortunately, cannot be used:

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

or

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

Option number 1, conceptually, causes an update with a user ID. Option number 2 provides a verb for working with the user ID.

In terms of consistency, which makes more sense?

---

Another variant:

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

This provides space for non-user pages. i.e.

• HTTP: // <tld> / stats

Answer 1

I would be careful to lead with userid - option # 2 - since (what exists) the directory structure is two different functions on user data. This is a user chart and user update.

This is a pretty minor point, although without knowing if there are plans to significantly expand the functionality of this thing.

• Will everything in the future be additional functions of foo, bar and baz for individual users? If this is so, option No. 2 becomes more attractive for the above reason - the user ID is the main data, it makes sense to start semantically with it.
• Are you going to add non-user functions? The host with the header directory may make sense then - / user / 1234 / update, / user / 1234 / chart, / question / 45678 / activity, / question / 45678 / stats, etc.

Answer 2

If you go with this scheme, it becomes easy to stop (behave) the robots from the spiders of your site:

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

This is because you can configure the /robots.txt file to contain:

  Disallow /update/ Disallow /chart/ 

For me, this is a good bonus that is often overlooked.

Answer 3

Option # 1 follows the general ASP.NET MVC examples. Some of the examples in Model View Controller take the form {controller} / {action} / {id}. .NET 3.5 quickstart when routing has a table with valid route patterns:

Route Definition - URL Matching Example

{controller} / {action} / {ID} - / Products / shows / drinks

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

Blog / {action} / {post} - / blog / show / 123

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

{locales} / {action}
- / ru-US / show

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

Answer 4

I personally like this style because it supports the user equally, but gives you a concrete idea of ​​them.

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

If you went the other way, I would expect that you can see everything under / update or / chart, and then narrow down the user.

Answer 5

Go with the last one; URLs should be hierarchical (or at least users read them this way by analogy with local directory paths). Here, the focus is on the various representations of a particular user, so the “user” is a more general concept and should look first.

Answer 6

I simply answered the question "How do you structure URL routes?" with my opinion on how to make RESTful URLs hacked and user friendly. I think it would be better to link than to write something like this in this question, hence the link.

Answer 7

I agree with the contextual point of view, an application followed by parameters makes much more sense to me than a surrogate key for an element, followed by the context of what is the subject. Ultimately, I would advise that it is ever more natural for you to program.

Answer 8

The convention says an object / verb / identifier, so it should be:

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

(I just noticed that matches your updated question :)

So yes, No. 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 9

If you have a list of users, I would introduce a user segment:

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

If you can only see your data, that is, users are invisible to each other, you do not need the user ID, since you can draw a conclusion from the session, in which case:

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