URI/URL Principles and Policies
On September 19 I wrote about my dreams for URI/URL nirvana. This post will expand on those ideas and take them a little further. I will talk about four principles that I believe, and then give my ideas for a policy for state URLs.
- First of all, I believe that URL design is important. Not only is it a tool through which a resource gets branded, but it should also be a permanent reference to the resource named, regardless of the method of delivering that resource. For example, everyone expects http://www.utah.gov to bring up Utah's official site, no matter who is providing it, what server it is located on, or who has access to it.
- URIs or URLs should not change. Having permanant URIs solves a lot of problems, and ensures that people will always be able to find the resource. Now, I am not arguing for keeping domains with state.ut.us or innerweb in them. But I would contend that once we have converted to utah.gov on all our sites, and we have ensured that our URIs are well designed that we leave them alone.
- Also, URLs should not indicate properties such as access. That is why I am against having components of the URL indicate access to the resource or security level, such as "innerweb" or "mydesk" for sites that are not a part of that system
- URIs should be designed with an eye towards implementing real XML web services and conforming to RESTian principles.
I hope that our policy will reflect the principles listed above. Here are some components to that policy:
- All domains will have a maximum of 4 levels with reasonable word lengths. For example, payroll.mydesk.utah.gov would be allowed.
- All state domains will be subdomains of utah.gov.
- Domains will not have elements that indicate the intended audience or access level. For example, employee-facing applications, or applications behind some kind of authentication system will not have domains with words that indicate that information.
- Standard three-letter abreviations or single word references to agencies will be used when referring to agencies.
- Whenever possible, content negotiation will be used to minimize the use of extensions.
- Domains will be selected as a permanent resource indicator for the resource in question.
How about some examples of this policy in action:
Example 1: Finance has a new payroll system that is a service offered by the employee portal. Some acceptable names would be payroll.utah.gov or payroll.mydesk.utah.gov (because it is a featured service of the employee portal).
Example 2: Tax has a new application intended for exclusive employee use. It is not their employee website, nor is it a service that is associated with the employee portal. It is an application that manages data collected on fraud cases. An acceptable name would be fraud.tax.utah.gov.
Example 3: ORS has an employee website that will require authentication. Ors.utah.gov would be ideal. Of course, inclusion of the info or services available to ORS employees on the enterprise employee portal would be even better, but until then I would stay away from naming employee-focused internal sites with mydesk.
A word about authentication/authorization and the "innerweb" concept. With the advent of UMD and the ability to store user information for the public as well as for state employees, the line of demarcation between what were formerly known as "innerweb" sites is blurring. Or, should I say, the concept of "innerweb" is obsolete. To indicate a realm in a domain is not condusive to cutting edge web services technology and architecture. We should steer away from it.
These are just my ideas on domain naming and URLs/URIs. I would love to hear comments.
2:42:03 PM 
|
|
