Dont Put Guids In Urls

GloballyUniqueIdentifiers should not be part of UniformResourceLocators that are read and typed by humans, because they are aesthetically unpleasant. For example, consider:

http://www.gotdotnet.com/Community/Workspaces/workspace.aspx?id=d589225d-988f-4d93-b8b9-c368e1985ddd

The query string in the example URL is a GloballyUniqueIdentifier. Some GUID generators generate GUIDs containing non-alphanumeric characters, such as curly braces, which are most unpleasant from an aesthetic point of view.

Therefore programmers, including ContentManagementSystem programmers, should consider the aesthetics of using GUIDs in URLs that need to be human-readable, pleasing to the eye, short, and easy to type. (These may be IncompatibleGoals.)

But not all pages have those needs of their URLs, and the aesthetic pleasantness of URLs is only one factor in the design trade-off of a Web application.

Discussion

Okay, this is true enough, but... where have you seen such things? I see similar URLs all the time... but they're not read or typed by humans, they show up when you're in somebody's database-driven Web site and you're looking at a particular record or table. Sometimes they're copied and pasted, but never typed by hand. For this sort of thing, there's bound to be some kind of alphabet soup at the end of the URL, and a GUID is no worse than any other sort. -- MichaelGates

I believe the above example was copied from SushiWiki. -- RandyStafford

There's a nice Web site out there called Make a Shorter Link. It's not bad. http://makeashorterlink.com/?H36612772

IMHO, sites like purl.org and makeashorterlink.com are silly and dangerous. They force a centralization of URL to resource resolution, and break one of the central ideas of the Web... namely, decentralization. -- JeremyDunck

One problem with a GUID-based URL is that it might get broken across lines when copied, pasted, and sent in an e-mail, and then the recipient can't just click it in the mail reader.

Maybe this topic should be renamed "DontCreateLongUrls?".

Reminds me of the military guy in Monty Python... "This is just plain silly..."

Simple URLs? No such thing. I see people using backslashes instead of slashes all the time. Colons? Fuggadaboutit. Nope. This argument is a RedHerring, IMHO. Cut and Paste errors can happen with short URLs almost as easily as long ones. Unless you have those big honkin' 1000 character URLs, which you really can't get with a guid-based URL, because a GUID is guaranteed to be 36 or so characters long. That's really not too long in my book. Ever looked at those session URLs created by some app servers?

Aesthetics has NOTHING to do with it. Now, if you wanted to say something like, "GUIDs in URLs obscure the meaning of the URL." THEN you will get my support!

I think it's dangerous for anything but a human to attempt to derive any meaning from the text included in an URL. That is, URLs are supposed to be opaque (http://www.w3.org/DesignIssues/Axioms.html#opaque), and guessing at the details of the resource content based on anything in the URL is a BadThing.

It's not unusual that a human would want to do exactly that, though. Lopping off the end of a URL to find the 'containing page' is a fairly normal thing for the adept user to try if he doesn't immediately see the link that he wants. http://www.useit.com/alertbox/990321.html

Anyway... It's a common problem (IncompatibleGoals) in application development that for any ID to be -only- an ID, it must never be shown to the user. As soon as you show an ID to the user, it can have rules applied to it (like "it needs to be short", or "it must be sequential", and it muddies the utility as a programmatic ID. Of course, never giving the user a mechanism to retrieve something is not very useful, either. Can anyone argue that GUIDs as querystring parameters are not programmatically useful? Can anyone argue that GUIDs in URLs are not a bother for the user? It's an imperfect world we live in... It seems like there should be a pattern to address the problem of how to create loosely coupled IDs. That is, how to create a programmatically useful ID, while making a loosely matched pseudo-ID which is useful to a human. Some resolution mechanism would decide (or ask the user for a decision) which programmatic ID they meant. I didn't see anything on this in the PatternIndex. Comments? -- JeremyDunck

There's really no need to single the GUID out as a special case. The URL of this page is http://c2.com/cgi/wiki?edit=DontPutGuidsInUrls, which isn't exactly pleasing to the eye either.

Now if you were to say "don't put GUIDs in displayed links", that would be an entirely different matter.

Actually, the URL for this page is http://c2.com/cgi/wiki?DontPutGuidsInUrls. What's not pleasing about that?

The presence of (1) the "cgi" directory in the path, and (2) the "wiki?" prefix on the page name. Both expose behind-the-scenes details of how this wiki works, and add no meaning. They are the URL equivalent of MagicNumbers.

See http://www.w3.org/Provider/Style/URI.html for some explanation of why it's bad to expose implementation details in this case. Summary: they will change, but your URLs should not.

There are two general ways that data can be passed through a form. After filling out a form, or a search bar you can send the data to the server using either the POST or GET method. The GET method will append the data to the URL, whereas POST will send it in the background. POST should be used wherever possible (such as when you need to send 1,000 characters of data). However, if you use POST the user can't bookmark the Web site. This is usually fine in many cases, but if you are running an online catalog you want to make sure that users can bookmark the links for a product to access it again. So really, there are methods of sending data through the Web browser in the background and I'm surprised many Web sites still don't use them. -- BlakeMason

I disagree with BlakeMason's assertions above. The HTTP verbs GET and POST have differing purposes, and saying "POST should be used wherever possible" is like saying "run" should be used wherever possible. It's clearly not true. It's hard to overestimate the usefulness of referenceability, and I think that every useful resource on a site should have a URI. Otherwise, you're making your site's information less accessible, and shortening the lever of the Web. Now, POST exists for a reason (state-changing input), and it's not a bugaboo. A login is a great use of POST, because it changes the state of the server, and the results of URI requests would return different information after logging in. But hiding data by using POST just to make pretty URLs is exactly the sort of hack I think needs to be addressed with a pattern.

Check out http://www.wunderground.com/US/TX/Dallas.html or http://www.google.com/search?q=considered%2Bharmful for useful resources that are easily referenceable, but could have (following the short-URL at-all-costs mindset) been implemented using POST. The Web (and the world) would be a poorer place if resources were hidden behind POSTs.

-- JeremyDunck

I put GUIDs in URLs that I mean to not be reused later (things like the insides of webapps). -- JoshuaHudson

CategoryInternet