I’ve been writing about the benefits of moving to a RESTful architecture for awhile. REST stands for Representational State Transfer and most, if not all, web enabled applications are built on it. This kind of standardized communications stack has a lot of benefits. It reduces the friction of using different technologies as a part of the system and ensure your API will remain compatible with new consumers far into the future. RESTful communications have encouraged more and more systems to interact with each other and once this starts happening in your organization, new and previously difficult ways of using your data becomes convenient and cost effective.
State Is Complicated
Even within a single system the complexity of a REST API and the objects it exposes can become quite complicated. Once we start thinking about systems of systems, however different challenges start surfacing. If you’ve been exposing database IDs (primary keys or foreign keys) to your client and expecting it to use these IDs to make decisions on how to manage your data, you might be creating an unsustainable API. Database IDs are very convenient to utilize, since they are supposed to be unique identifiers to a piece of data on our system. It is also much faster to pass around a collection of IDs, than complicated business keys.
Leaky IDs are Bad
There are security risks associated with directly exposing system internals out to the public. A public network is not just the internet. We must consider VPNs and other company wide WANs also as public networks. All it takes is a disgruntled employee, a juvenile prankster or a compromised computer to cause serious damage to the company and the trust in the system.
The article The S in REST recently surfaced on Hacker News addresses the challenges of working with REST head on. Ted Dziuba proposes the Representational Value Transfer (REVAT) system, an innovative solution to overcome state consistency and maintenance complexity issues.
REVAT to the Rescue
The simplest example of REVAT is in trying to identify an entity being consumed across multiple systems that are internal and external to the system. We’ve established why we shouldn’t be using Database IDs for this purpose and once we start thinking about systems of systems, parts of that maybe completely opaque to you, sending Database IDs around becomes a further challenge. 20 years from now will the entity I’m looking for retain the same Database ID?
Business keys have other challenges. A key that use to identify an entity might be valid for a long period of time, however once this key leaves my system, the meaning of it is easily lost in systems that don’t have an understanding of your domain. Business keys can also become quite long and complicated and frankly sometimes trying to come up with a business key to an entity that doesn’t naturally have one is a game I don’t like playing.
One in 3.4 × 1038
Enter UUID or GUID. UUIDs make universal sense. They are guaranteed to be universally unique across systems forever. Using UUIDs to identify entities makes a lot of sense. I can query any system in the world with a UUID to see if it contains that entity I’m looking for, leading to a very resilient expansion of our information system.
If someone in the future turns on a phone that was built today and tried to launch an app with some data stored in it the app is guaranteed to not to work and furthermore there’d really be no hope of restoring or making sense of a good portion of the data. However, if the app stored its relations to other entities using UUIDs then it might just be possible reconstruct the information within the app. That’d be the true test of a system that’d stand the test of time.
I highly encourage you to read Ted’s article for more details.