[wp-hackers] Ignore Portions of URI

[Mike Schinkel]

Hi All:

Hate to get mired into this debate, but finally I can't help myself but make the following points (and I've spent a lot of time researching URL design, see: http://blog.welldesignedurls.org.)

URL fragments and URL parameters create different architectures and really should be used for different use-cases.  

When using URL Fragments you are essentially creating a mini-app within one URL where the fragment is ideally being used to capture and restore state when a user bookmarks the URL. URL fragments are handled completely by the client although some (all?) search engines will index fragments with their URLs. 

URL Parameters are used when you want the server to generate a completely different response representation upon a request. BTW, URLs with parameters (i.e. http://example.com/?p=3) and URLs with parameter data embedded (i.e. http://example.com/about/) are equivalent for the purpose of this discussion.

For example the project that I am working on today will use both parameters and fragments for a media gallery with video and photo tabs.  URLs will look like this:

http://example.com/gallery/videos
http://example.com/gallery/photos

The Video Gallery will have "Channels" and "Videos" where a Channel contains one of more videos. The Photo Gallery will have "Albums" and "Photo Sets" where an Album contains one of more Photo Sets which contains one of more Photos. We want the screen to refresh *between* the video and photo section since we are using different players and all the data on the screen chances but we want full interactivity and quick response *within* the video and the photo galleries *and* we want to be able to bookmark the current state. These are some example URLs w/fragments we'll use:

http://example.com/gallery/videos#vc3v52
http://example.com/gallery/photos#pa2ps7p86

In those fragments vc=Video Channel, v=Video, pa=Photo Album, ps=Photo Set, and p=Photo with the numbers being their respective IDs from the NextGen Gallery (I'm planning to enhance NextGen to support video.)

As the user clicks around in the video and/or photo gallery we'll use Javascript to update the URL to indicate the current "state" of the page/mini-app. When a user returns to a bookmarked URL with those fragments we'll use Javascript to restore the page state to the Channel/Video and/or the Album/PhotoSet/Photo that was being displayed when the URL was bookmarked.

That said, you can potentially use page refreshes (URLs w/parameters) for everything or use in-page navigation (URLs w/fragments) for everything but each creates a different architecture and thus should be used in the use cases that best fit the architecture. For example two completely different pages shouldn't use URL fragments to differentiate but a page with a single cohesive purpose that requires lots of interactivity (like, say, a file manager for server files) should use URL fragments and it should regenerate the relevant state the page was in when bookmarked from the URL fragment.  BTW, this is one thing that most Flash apps do NOT do well, unfortunately.

So in summary, URLs w/parameters and URLs w/fragments are both valid architectures but each should be used with their respective appropriate use-cases.

HTH.

-Mike Schinkel
http://mikeschinkel.com/

P.S. The HTTP spec says that it is up to the client to interpret the URL fragment and that mostly it should do so based on content type. For example, think of how fragments work with PDF files. In the case of HTML the browser does have default behavior for fragment, i.e. repositioning the viewport, but for HTML+AJAX/AHAH-based apps repositioning only is too limited. In essence, when we use fragments we should design them as if we were designing our own new custom content type that is based on HTML+interactivity.