Thinking in URLs

by Eric Larson

One thing I've noticed when designing applications of late is heavy use of URLs. Rather obviously, RESTful services have URL interfaces that expose the service to the web. I personally think RESTful service should be "mountable" at any other URL, which requires a bit of care in the URL arena. Beyond the obvious publishing of services and resources, URLs have been playing a helpful role throughout the applications I'm working on.

Namespaces are one area where URLs seem to always come up. URLs make for great namespaces because they are essentially infinite and often referencable, even thought they don't have to be. Basing your namespaces on a domain you own is a reliable way to make sure you are avoiding collisions, while offering something a little more unique than a PURL address or something similar. Also, within the scope of a framework, actual addressable namespaces can provide interesting results within the scope of communicating with other services. Also, when I say namespaces in this context, they do not have to restricted to XML Namespaces. A namespace in this context simply provides uniqueness, similar to a hashing function.

This combination of uniqueness and referencability is a pretty powerful combo. In Python WSGI web applications, there is a dictionary that is passed along to the underlying application and middleware. The dictionary keys are often namespaced in one way or another to avoid collisions with other middleware. A simple prefix map using actual URLs could help the issue and make accessing items in the environment dictionary simpler. I know in the past I've used helper functions to get and set items in the environment dictionary, but having my own key that maps to a URL namespace could help reduce my own typing errors while making it explicit what I am doing.

I think what I like about using URLs is the implied linked nature. Using something like a UUID for some ID is fine, but when you utilize a URL there is an implicit connection with some addressable resource. When you select the IDs from your database and you get a few thousand UUIDs the reasoning becomes more obvious. Some might argue that depending on some semantics within an ID is bad idea, and to an extent I agree. With that said, when the service crashes hard and you are tasked to rebuild it from scratch, you might think differently.