URI design - Make it central to web application design

The beauty of HTTP is its simplicity. It is clear text protocol which essentially lists few methods (GET, POST etc) to operate on a resource. One of the cornerstones of HTTP protocol is concept of URIs. URI which is the address to reach a resource. A resource which could be abstract or physical. Simply put, URI is a string of characters which is reference to a resource. But it is amazing how this simple concept has been misused or underused. Architects and designers of enterprise software have hardly designed systems with URIs in mind (at least in pre-REST hype phase). So much so that sometime tasks a system is designed to do become hard or impossible to do.

Consider a system which is designed to act as web based employee directory or database. System records everything from employee's basic information, his photograph, his location, his contact details etc. So the primary function of such a system, one would assume is to, operate on set of resources which are employee records. And hence one would assume that every employee record would get represented by a URI which could be something like http://someempdir/employees/a/jhonSmith . This would mean that by passing the URI around, an employee can present his information to whosoever needs it. Plain and Simple.

But what happens if system is built ignoring basic tenets of URIs and HTTP? What if employee records are not URI reachable because system is perhaps using POST requests to do something which essentially is a GET request? So to access an employee record, one has to login to system and then use search functionality and then click on record to see the details but URI could be something like "http://someemdir/portals/wsd/somesbs/m orebs/search.asp?a=bs, making no sense to anybody. It would stay same for Jhon Smith and same for Ramesh kumar making It useless .And what if system does use Get request to access an employee record but generates URIs which can be mind numbing like http://someemdir/portals/wsd/som esbs/morebs/readuser.asp?resource=user&view=broad&application=e mpDirectory&dn=hN%3id=4%2COU%3Dusa%2COU%3DIN%2COU%3DEmployees%2CDC%3Dcom%2CDC%3Dabc%2CDC%3Dcom.

Now consider if I am handling a group of 100 employees and want to keep record of their details and share it with others, I can't use the employee database as I can't reach any employee record outside the system context. I can’t send a URI like http://someempdir/employees/a/jhonSmith to someone who needs Jhon's details. So I will have to create my own little database in an excel sheet and I will ask 100 guys to update it with their information. Employee information now is in two different places and I have to make sure that when guys leave my group or new guys join, I update my own little database and ask everybody else to make sure that their information in my database is in synch with what they have in their respective records in employee directory . And for all practical purpose the big database is all but redundant for me.

If system was designed with some attention to URIs and how information was to be represented, My task would have been easier. I would have just tracked a list of 100 URIs in a sheet. A list of pointers to central source of information. Now if there are 50 other people like me handling group of employees, one can imagine the time wasted in this inane activity of maintaining duplicated information. One can see many such examples in most of enterprise systems and that is why considerable amount of time is spent on unproductive tasks. Lots of times, manual tasks are done to gather information which is lying in all sort of system but is useless because of unnecessary barriers created in accessing it. A barrier could be as simple as not having readable, proper URI for a resource. From my own experience, the reason for this is overly focus on technologies, frameworks and implementation while designing a system, rather than key principles of information management.

While designing a web based system, it is important to consider URI design. In fact that should be beginning of design. Design how URI landscape would look like and how all resources in your system would be represented by URIs. If a product doesn’t support it, junk it.