Identifiers

We have IDs in port OS.

The format of the ID is in the format of

<namespace>/<owner-type>/<owner-id>/<resource-type>/<resource-id>

For example:

port1/account/bob/endpoint/lightbulb-zero

Breaking this down:

• port1 is a namespace that contains group of IDs.
• account is the type of the owner of the resource.
• bob is the unique identifier of the account that owns the resource.
• endpoint is the type of the resource.
• lightbulb-zero is the unique idenntifier of the account that owns the resource.

Basically, that ID is bob's lightbulb-zero in the port1 namespace.

Technical details on why

Encoding namespaces into the identifier space

Storing a namespace allows us to generate new identifier spaces that operate independently when needed.

Encoding ownership details into the resource identifiers

The identifier space encodes ownership details so that the access control system ends up being independent from the resource systems.

The access control space can work independent of having to look into the various resource services.

Versioning

The current ID space is the v1 id space. We expect new versions to be introduced in the future, and newer versions will encode a version prefix like /v2/port1 to denote the difference.

Length

The names are generally quite long, and should be treated as opaque identifiers from the customers perspective as much as possible. One choice we can make later is to make the names shorter using aliasing. We leave this for later.

Why not use URIs?

It sort of is. From a more generic URI perspective, the resource is more generally:

• https://api.portoperatingsystem.com/port1/account/bob/endpoint/lightbulb-zero

We mostly remove the top level domain information.