Allow unique IDs across resource types
Issue
During discussions of the development of DestinationData's reference server, a question emerged regarding the standard's stance on how server implementations define the ID of the resources they store.
Currently, resources are identified by a combination of two properties, a "type"
and an "id"
, where these properties are combined in a URL dedicated to that resource. For example, following the adopted RESTfull API style, the agent resource with the "id": "1"
would be available through a URL like "https://www.example.com/2022-04/agents/1"
.
Recently, discussions about the possibility of user-defined IDs during resource creation (see #31 (closed)) have already made, leading to the decision that each server implementation can define its own syntax and constraints for IDs (e.g., while server A uses UUID syntax for resources' IDs, server B uses incremental numbers). Now, the experience with the reference server raised the question if servers could define IDs that are unique across all resource types. In other words, there are two options available:
- IDs MAY/MUST be unique across resource types: if there is an agent resource with
"id": "1"
, there CANNOT be an event resource with"id": "1"
- IDs MAY/MUST be reusable across resource types: if there is an agent resource with
"id": "1"
, there CAN be an event resource with"id": "1"
Proposal
The members in the most recent meeting have discussed towards allowing servers to decide whether they wish to enforce unique IDs across resource types as this is a decision that may affect directly their own solutions for data storage (e.g., affect the design of tables and constraints in relational databases).