Responses include related resource links

A response that includes userId but no information about how to fetch the user forces every consumer to hardcode the URL pattern /api/v1/users/{userId}. When that pattern changes, every consumer breaks — and there is no machine-readable artifact that could have warned them. iso-25010:2011 compatibility.interoperability is the direct gap: the API returns foreign keys but not the means to navigate them, making the API partially self-describing at best and requiring consumers to maintain their own URL construction knowledge.

Add basic resource linking to make responses partially self-describing. Even just self URLs are a meaningful improvement over bare IDs:

// Before -- ID only, consumer must know URL pattern:
{
  "id": "order-123",
  "userId": "user-456"
}

// After -- with links:
{
  "id": "order-123",
  "userId": "user-456",
  "_links": {
    "self": "/api/v1/orders/order-123",
    "user": "/api/v1/users/user-456"
  }
}

Start with self links on every resource — that alone lets consumers build shareable URLs and canonical references. Add related resource links for the two or three relationships consumers navigate most frequently.