Identify the Identity (Part IV: Abbreviated UUIDs for Application & Resource Identifiers)

Part III of this series of posts discussed how application identifiers can double as resource identifiers for RESTful APIs. This final part discusses the situations where using meaningful application identifiers is not an option and what to do instead.

When Application Identifiers Are Not a Good Fit

So, in what situations would the adoption of meaningful application or resource identifiers not be an option?

Well, if you are an advocate of HATEOAS (despite my protestations in the last post), you will argue that exposing them as resource identifiers is not good practice.

In addition, despite all my clamouring in previous posts to use application identifiers, this was always caveated as wherever possible. There are indeed situations where there is no logical candidate as application identifier for your application object. This constraint is further compounded by the fact that you need to find a logical candidate as application identifier for all your aggregate objects in order to have consistency across your application design.

So Now What?

OK, so now that there are situations where the concept of an application identifier is all well and good but you can’t establish one for all of your aggregate objects, or even if you have, you might be a HATEOAS zealot and don’t then want to expose the application identifier as a resource identifier. Then what? What will you use to unique identify objects or resources?

Well, you could devise your own coded number system where each character means or represents something, which eventually with enough characters ensures uniqueness in your application. That is until domain rules change and it no longer does. Then you have a major problem.

That is why I prefer an arbitrary numbering system. Of course it feels like we are back to square one where we use a code-managed arbitrary number system – see Part I for the basics. However we need more than the basics here as a UUID (or GUID if you live in a Microsoft world) is functional but not really practical. That is, while it ensures that the identifier is arbitrary and also unique, a 32 character reference cannot be described as consumable or user-friendly.

Just picture it, you are involved in the development of a new mortgage application management system for example. No logical application identifier can be established from the attributes of an application aggregate root object so you decide to use a UUID as an arbitrary number. The end users are more than likely to reference mortgage applications offline as well as online using, you guessed it, this mortgage application reference number. Would you like to be that mortgage analyst or underwriter shouting out or writing down a 32 digit series of random characters like the one below?

 

ffaa98aa-7b6d-45f2-980d-000a596a917f

 

And we haven’t even considered how this aesthetically looks as part of a web or API URL. This is why if you look at GMail for example, each unique email has a 16 digit identifier rather than the unwieldy 32 characters offered by a UUID.

 

Screen_Shot_2016-01-06_at_3_07_38_PM

 

 

Sure, its not ideal but it’s infinitely better.

Abbreviated UUIDs

So how then do we generate an abbreviated version of UUIDs to provide a more practical and consumable alternative?

Well, step 1 is to code-generate a UUID (see Part I again for a .NET example).

Step 2 is to then use an algorithm to shorten the UUID, much like what I’ve done in the C# code below

In this example, I’ve used this as a method extension so that it is easily accessible to wherever I’m using System.Guid objects, but of course this is optional.

This in turn produces an abbreviated version, so  ffaa98aa-7b6d-45f2-980d-000a596a917f   becomes   qpiq_2178kWYDQAK.

While still not ideal, its a vast improvement on the original UUID and a lot more consumable.

Summary

As stated in the introduction to this post, across this series of posts I’ve tried to break down the concept of identifiers, why their are conceptually important to you application design (both internally and externally) and how to deal with implementing a practical arbitrary alternative with full and shortened UUIDs.

If you haven’t already read them, the other posts in this series are

Part I: Technical Identifiers
Part 2: Conceptual Application Identifiers
Part 3: Resource Identifiers

Leave a Reply

Your email address will not be published. Required fields are marked *