...

This applies throughout the whole architecture regardless of which team writes the API or what language it is written in.

"id" and "type"

The "type" should always be a StudlyCase name of an entity that exists in our Ubiquitous Domain Language, for example: "ExternalVODProductMapping" or "User"

The "id" needs to be the primary key of the entity whose state is being represented in the response.

For most cases we use a primary key that is an auto-incrementing "id" column in a table that models an entity.  The value of this attribute should be used as the "id" field.

For cases where we use a composite primary key then the "id" value in the response needs to be a JSON string containing the names of the PK columns and their values, for example like this:

{
  "id": "{'product_id': 123,'external_product_id': 456}"
}

Hydration

Every API MUST avoid retrieving data from the database unless it is directly relevant to the API endpoint

...