Skip to content

Proposal to reserve "version" member at top level of resource objects #600

@scott-mcdonald

Description

@scott-mcdonald

Currently each resource has "identity" via the "type" and "id" top-level keywords at the top-level of a resource, but a resource can be at a different "version" based on updates, etc.

I propose adding an optional top-level resource keyword called version that is an opaque identifier/value (read that as string) of the current version of the respective individual resource. You can then use "type", "id", and "version" to uniquely identify a resource and at what version this representation is. I believe having the version be a known property on a json-api compliant resource further refines the "identity" of the resource and makes certain client-side workflows easier, i.e. optimistic locking, client-side caching, etc.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions