EAM API: only UUID format for IDs is too strict

[gainsley]

Problem description

AppId, EdgeCloudZoneId, etc IDs are currently defined as strings with format UUID. Our platform currently uses ULIDs. It's not really feasible for us to convert to use UUIDs because of existing deployments. We would like to add ULID as an additional allowed format for IDs.

Possible evolution

New IDs would have the following type definition:

type: string
anyOf:
- format: uuid
- format: ulid 

Alternative solution

An alternative would be to remove the format requirement completely. As long as the platform can guarantee that the IDs it generates are unique, then any format should be ok.

In particular, platforms using an SQL database will likely have IDs of type uint64.

An argument that IDs must be unique outside of the Edge Cloud Platform (i.e. for federation) does not seem like good practice, it would better to scope foreign IDs to the partner federation so there is no possibility of conflicts with our own IDs.

Additional context

[gainsley]

See also #259: For federation EWBI API, AppId cannot be a UUID.

[gainsley]

Any comments on this? The only potential reason to specify a format would be because these IDs are used in URL paths (i.e. DELETE /apps/{appId} and it would be nice (but not necessary) for them to use URL-safe characters. But non-URL-safe chars can always be encoded. Otherwise I don't see any reason to restrict the ID format.