99

When using JSON Schema and Open API specification (OAS) to document a REST API, how do I define the UUID property?

Slava Fomin II
  • 26,865
  • 29
  • 124
  • 202
  • Also see: https://github.com/json-schema-org/json-schema-spec/issues/542 and https://github.com/json-schema-org/json-schema-spec/pull/715 – Christophe Roussy Jun 28 '19 at 10:29

3 Answers3

137

There's no built-in type for UUID, but the OpenAPI Specification suggests using

type: string
format: uuid

From the Data Types section (emphasis mine):

Primitives have an optional modifier property: format. OAS uses several known formats to define in fine detail the data type being used. However, to support documentation needs, the format property is an open string-valued property, and can have any value. Formats such as "email", "uuid", and so on, MAY be used even though undefined by this specification.

For example, Swagger Codegen maps format: uuid to System.Guid in C# or java.util.UUID in Java. Tools that don't support format: uuid will handle it as just type: string.

Helen
  • 87,344
  • 17
  • 243
  • 314
  • 1
    This is only correct for OpenAPI 3.0, and not correct for OpenAPI 3.1 or above. – Relequestual Oct 11 '21 at 08:48
  • @Relequestual do you mean the fact that since JSON Schema 2019-09 the `format` is an annotation and not an assertion? Or something else? – Helen Oct 11 '21 at 09:31
  • 1
    Additionally, OpenAPI 3.1 uses JSON Schema fully, while OpenAPI 3.0 uses its own schema format. As of JSON Schema 2020-12 (which is what OAS 3.1 uses), `format` is annotation only, but you can use an assertion version of `format` if you define a JSON Schema dialect using the "format assertion Vocabulary". – Relequestual Oct 11 '21 at 09:36
43

The only way I found so far is to manually specify the RegEx pattern as reusable schema component:

openapi: 3.0.1

paths:
  /transactions/:
    post:
      responses:
        200:
          content:
            application/json:
              schema:
                type: object
                properties:
                  transactionId:
                    $ref: '#/components/schemas/uuid'

components:
  schemas:
    uuid:
      type: string
      pattern: '^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$'
      # the regex above limits the length;
      # however, some tools might require explicit settings:
      minLength: 36
      maxLength: 36

But, I would definitely want to use a more standardized approach.

Slava Fomin II
  • 26,865
  • 29
  • 124
  • 202
  • 1
    Can I suggest adding the string delimiters: `pattern: '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}` – Ktipr Dec 16 '20 at 12:45
  • 2
    The dashes are optional in the uuid spec, so maybe `pattern: '^[0-9a-f]{8}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{12}$'` and `minlength: 32`. – Papooch Feb 23 '21 at 15:10
  • This is hint I needed to address a problem where the openapi tools were validating the UUID format. Our implementation is adding a prefix, e.g., `Gcc55edda-7acd-4128-877d-02b94430896a`. Just using `format: uuid` would fail the tooling where the path parameter used it. I created a "custom UUID" using this answer! Thanks! – javafueled Jul 02 '21 at 19:57
  • Does pattern make value required (imagine minLength does not present)? – Simon Logic Oct 28 '21 at 14:45
  • 1
    @Papooch do you have a source for the optionality of the hyphens, please? I couldn't verify that statement, but would be interested in such a more compact rep. The RFC4122 includes the hyphens directly in the ABNF, and the ITU recommendation X667 says the hyphens "shall" be included. – hiergiltdiestfu Feb 18 '22 at 06:14
  • 1
    @hiergiltdiestfu It turns out I was mistaken. Seems the spec does not allow omission of the hyphens, *but* most of the systems that consume UUIDs that I've worked with allow it, so it was my assumption. If you are interested in a compact representation of UUID for *your* system, check out https://www.npmjs.com/package/short-uuid – Papooch Feb 18 '22 at 09:11
  • @Papooch thanks for the quick feedback. In our system we actually use a base 36 representation of half a uuid formatted similar to an ip for all ids that need to be as unique as possible while still being marginally user-friendly - they then look like "13t.zr1.9qf.aa0s" and we call them MagnumIDs. That works fine, but its ultra custom after all, so thanks for the pointer to the short-uuid, I'll check that out. – hiergiltdiestfu Feb 18 '22 at 20:42
  • 1
    @Papooch It seems already minLength 32 resulting from the regex. Aha, it's for some strange tool. – Lukas Salich Aug 24 '23 at 12:11
27

Since the question was originally asked the JSON Schema spec has been extended to provide built-in support for specifying and validating that a JSON field of type string is a UUID - specifically that it adheres to the format of a UUID as defined by RFC4122, e.g. “f81d4fae-7dec-11d0-a765-00a0c91e6bf6”.

The support was added in JSON Schema spec version 2019-09 (previously known as draft-08). The JSON Schema Validation component spec was extended such that the existing ‘format' keyword that can be specified for schema fields of type string now supports a new built-in format named "uuid".

The example JSON schema below declares a (mandatory) field named "id" of type string that must be formatted as UUID -

{
  "$schema": "http://json-schema.org/draft/2019-09/schema#",
  "title": "My JSON object schema",
  "description": "Schema for the JSON representation of my JSON object.",

  "type": "object",
  "properties": {
    "id": {
      "description": "The unique identifier for my object. (A UUID specified by RFC4122).",
      "type": "string",
      "format": "uuid"
    }
  },
  "required": ["id"]
}

Note that at the time of writing, the section of the JSON Schema user guide ("Understanding JSON Schema") covering examples of built-in string validation - JSON Schema Reference > Type-specific keywords > string > Format - doesn’t mention UUID supports, as it’s out of date - it currently only describes JSON Schema draft-7.

For the Java developers among you, the RFC4122 format used by JSON schema is compatible with the string representation of Java’s UUID class - it’s Javadoc also mentions RFC 4122.

For more details see -

Community
  • 1
  • 1
Neil Brown
  • 409
  • 5
  • 6
  • Unless I'm missing something obvious, the UUID format was not been implemented in 2019-09. See this example, which successfully validates even though ID is not a UUID - https://www.jsonschemavalidator.net/s/lWxTWkoP – David Gard Jan 07 '21 at 15:40
  • 4
    @DavidGard - your comment is very recent - but appears UUID has now been added? `{"id": '9151f21f-43ae-43b4-92f3-f4af67cdf544'}` validates... remove anything from that UUID, or replace it with garbage, and it fails validation now. – some bits flipped Jan 27 '21 at 23:53