The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Putting Unique IDs in URLs.

What's the conventional view of this url pattern:

www.mypage.com?id=5

...where id=5 is hitting a db table's unique ID. I've heard this is bad because it allows leeching. In my case, leeching simply isn't possible (for various reasons). I don't really want to add the complexity of a surrogate ID column with junk like "5_fbb1111_05405050_13365bbg" just to have something to stick in a URL query string.

Are there any other serious objections to putting db uids in a URL?
mynameishere
Wednesday, May 23, 2007
 
 
Other than it's poor SEO, I don't think it's a problem.

Many search engines don't like to see lots of big numbers, since it could mean SessionID's and the spider gets lost in those (potentially).
Eric D. Burdo Send private email
Wednesday, May 23, 2007
 
 
Short version: what you propose is fine.

Long version: What you've been told is wrong. First of all, imagine reading a URL that contains something like "5_fbb1111_05405050_13365bbg" over the phone to your mother. URLs aren't just magic clicky objects, they have to be human-readable. A good URL indicates both what's at the other end of the link and where it is in the structure of the site. A URL with a short numeric query string is the next best thing.

As for "allowing leaching", if your whole security system is based around the obscurity of the URL, it's broken and it will eventually bite you. If you've got your ducks in  a row, "www.mypage.com?id=5" is fine. If you don't, changing it to "www.mypage.com?thagomizer=5_fbb1111_05405050_13365bbg" won't help.

URLs leak out in all kinds of ways that people don't expect. Ignore all advice from people who think making your URLs look like encrypted line noise is a security mechanism.
clcr
Wednesday, May 23, 2007
 
 
One potential problem is that if you need to repopulate the database at some point then the IDs could change, which might break any existing URLs.
John Topley Send private email
Wednesday, May 23, 2007
 
 
John made an important point. But you just need to make sure your IDs are permanent, i.e. if they are internal and can change then use a simple permanent public identifier, but still a simple number.
Ben Bryant Send private email
Wednesday, May 23, 2007
 
 
A case in point is this forum which uses a permanent numeric ID in the query part of the URL (after the question mark):

default.asp?design.4.499004.5

It also uses "design.4." as a way of indicating which forum it is. And the ".5" at the end is the optional number of comments.

Your use of the id= parameter name is good.

A better system for this forum would be:

default.asp?forum=design;thread=499004;comments=5
Ben Bryant Send private email
Wednesday, May 23, 2007
 
 
"A better system for this forum would be:

default.asp?forum=design;thread=499004;comments=5"

Why?  It is longer.  Anyone who knows the significance of the numbering does not need the additional verbiage.  Anyone who does not is not going to be able to take advantage of it anyway.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Wednesday, May 23, 2007
 
 
"In my case, leeching simply isn't possible..."

Whatever mechanism you have in place to prevent leeching, can't you use that to track IDs? For example, if you have a session object that verifies identity, place the database reference in there as well.

The ID in the URL should only be used to identify the web page itself, with the additional constraint that anyone can view that web page if they know the ID. Using this forum as an example, it simply identifies the group and the topic. It doesn't identify anything else and that makes it ok.

If the database key uniquely identifies a web page and you have no problem showing that page to everyone who visits, then I don't see an issue. If the key identifies something about the user, or is connected in some way to the user, then take it out of the URL and put it into your anti-leeching mechanism.
TheDavid
Wednesday, May 23, 2007
 
 
"A better system for this forum would be:

default.asp?forum=design;thread=499004;comments=5"

Actually a better system would use hackable URLs e.g:

discuss.joelonsoftware.com/design/499004/?c=5

This would let you hack off the "499004" to go to a list of all threads in this group and hacking off "design" would ideally take you to a list of all groups. If something is in any way permanent or stateless then it belongs in the URL.
John Topley Send private email
Wednesday, May 23, 2007
 
 
John, yes, I agree your suggestion would be ideal.
Ben Bryant Send private email
Wednesday, May 23, 2007
 
 
The URL for this thread:
  http://discuss.joelonsoftware.com/default.asp?design.4.499004.9

Remove .4.499004.9 and you get a list of all threads in this group:
  http://discuss.joelonsoftware.com/default.asp?design

Remove the ?design and you get a list of all groups:
  http://discuss.joelonsoftware.com/default.asp

Of course, I can't imagine why someone would want to hack the JOS URLs given the copious links to the topic list all over the page and the obvious list of groups at the top.

Wednesday, May 23, 2007
 
 
The point is that URLs should indicate whereabouts you are in a hierarchy of information and should support hacking to get to different levels within the hierarchy. For these discussion groups, the group you're in and the topic within that group are hierarchical and as such should be intrinsic to the URL.

Transient state information such as the number of replies in a thread should be represented using query parameters.
John Topley Send private email
Thursday, May 24, 2007
 
 
Actually the number of comments doesn't belong anywhere in it. That is a hack that goes against the logic of URLs. Search engines see duplicate pages etc. But yes, if you want to put it somewhere, then put it in the query.
Ben Bryant Send private email
Thursday, May 24, 2007
 
 
>can't imagine why someone would want to hack the JOS URLs

Bookmarks.
dot for this one
Thursday, May 24, 2007
 
 
"...That is a hack that goes against the logic of URLs. Search engines see duplicate pages etc."

Now that you mention it, that's actually kind of interesting. It could be that in Joel's case, he deliberately wants to treat each comment added as a separate web page. In other words, incrementing the comment number is like incrementing the revision number.

I can't get them to come outright and say it, but I get the impression that the forums are really a front end to FogBugz, and treating each response as a new revision allows them to do version control kung fu on the tickets (the original topics), including branching.
TheDavid
Friday, May 25, 2007
 
 
The reason for incrementing the comment number is so that the link colors change appropriately.  You click a topic and the color changes to visited.  If someone adds a comment, now you have a new URL, and link color goes back to normal.
Almost H. Anonymous Send private email
Friday, May 25, 2007
 
 
Interestingly, if you have an account then the read/unread status of topics is now tracked server-side in FogBugz 6.0.
John Topley Send private email
Saturday, May 26, 2007
 
 
> The point is that URLs should indicate whereabouts
> you are in a hierarchy of information and should
> support hacking to get to different levels within
>  the hierarchy.

Sounds like the OO vs RDBMS debate. The identity of a thing is separate from the possible many navigation paths to get to the thing. So requiring the navigation path to make up the distinguished name really limits what you can do with that thing. By using IDs you can get to something without a context and that's more powerful and less subject to change.
son of parnas
Monday, May 28, 2007
 
 
URL QueryStrings are nothing but a way to pass name-value pairs using a GET to the server. Thats it. How or why you use them doesnt matter. So, using id=5 is perfect and a very reliable way to pass that data to the page. Great ting about doing it that way versus the "number-wach" systems some people on here suggest is query strings are easy to maintain, manage, modify, and update on both the server-side and client-side. They go through firewalls, proxies, and most security systems, are search engine friendly, and can be bookmarked. Cross-browser friendly as well, unlike some of the autpostback junk and other gimmics Microsft has come out with.

I think people still dont appreciate the power and simplicity of the query strings in web sites. If you keep it simple, and your id's are stable in the database and not tied to security-related data, then how you are using them is fine.  If you need extra security encrypt them but dont overdue it. If they are tied to very secure data, then encrypt, move to sessions, or the database layer of your app.
ranger
Wednesday, June 06, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz