Bearing in mind that I create ugly URIs as often as anyone, that I am simply answering a question, and that I don't want to pick on someone else's work:
(1) URIs should describe the resource they identify, not the technology used to create it. (Data persists, but technology changes.) So ideally, .cfm and .html file extensions are no-nos.
(2) Similarly, the URI in question spends most of its length describing the internal functions of the application, not the data itself.
(3) Speaking of length... that's a long URI, which will all-too-often be mangled when passed around in email.
(4) The query names that matter to the user are either opaque (Gindex, Pindex) or tightly coupled to the nature of the request (ID_FIRM_ABOUT). All other things being equal, you're better off with the far simpler "group", "person", and "firm". (Chances are gindex and pindex don't translate to "group" and "person", of course, but the URI design encourages such bad guesses.)
(5) In a broader sense, query-string URIs are troublesome in and of themselves. A good URI can be used as a unique, unchanging identifier... a primary key for the Web, in other words. Since query name/value pairs can appear in any order, it's very easy to have the same application linking to ?foo=bar&bar=foo in one place and ?bar=foo&foo=bar in another. Will the application still work? Sure. But the Web thinks you're pointing to different pages, which is only a good thing if you're trying to spam Google.
Having said all of that, thre are valid reasons to dispense with any of the above principles in a given situation, and no one is a Bad Person for doing so. But it's all worth bearing in mind as you develop.
--
Roger
JournURL
site: http://journurl.com/
blog: http://admin.support.journurl.com/
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
