The specification demands that the ID of a resource be of type UUID.
I would argue that there is no good reason to require a UUID type for a resource ID. Resource provider implementations can benefit from the freedom of using the ID format of their choice. In the case of the signalk-activecaptain-resources plugin, the resource entities are owned by a third party system outside of our control and are proxied by the plugin. The external IDs are of type integer. It would require complex mapping if we were forced to use UUIDs.
HrefAttribute:
type: object
required:
- href
properties:
href:
description: Reference to a related resource. A pointer to the resource UUID.
example: /resources/waypoints/ac3a3b2d-07e8-4f25-92bc-98e7c92f7f1a
allOf:
$ref: '#/components/schemas/SignalKHref'
SignalKUuid:
type: string
pattern: '[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-4[0-9A-Fa-f]{3}-[89ABab][0-9A-Fa-f]{3}-[0-9A-Fa-f]{12}$'
example: ac3a3b2d-07e8-4f25-92bc-98e7c92f7f1a
SignalKHref:
type: string
pattern: ^/resources/(\w*)/[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-4[0-9A-Fa-f]{3}-[89ABab][0-9A-Fa-f]{3}-[0-9A-Fa-f]{12}$
The specification demands that the ID of a resource be of type UUID.
I would argue that there is no good reason to require a UUID type for a resource ID. Resource provider implementations can benefit from the freedom of using the ID format of their choice. In the case of the signalk-activecaptain-resources plugin, the resource entities are owned by a third party system outside of our control and are proxied by the plugin. The external IDs are of type integer. It would require complex mapping if we were forced to use UUIDs.