Conceptual split between resources and public resources.

[stephenwf]

At the moment you can fetch the same Manifest at two URLs, one using the flat id and another using the slug / publicId. As an API consumer this causes the conceptual model of resources to break down a bit. They are the same resource, but have different behaviours and ways of editing and constructing things like paths and identifiers.

I wonder if having a more explicit split between these two types of resources would help.

"GET /manifests/abc123"
{
  "id": "https://example.org/manifests/abc123",
  "type": "Manifest",
  ...
  "publicResource": {
    "id": "https://example.org/some/path/to/manifest",
    "type": "Manifest",
    "slug": "manifest",
    ...
  },
  "parent": {
    "id": "https://example.org/collections/def456",
    "type": "Collection",
    "publicResource": {
      "id": "https://example.org/some/path/to",
      "type": "Collection"
    },
    ...
  }
}

So within an API representation of the resource, information about the public resource would be in publicResource and in the public resource (with IIIFCS-Show-Extras header) it could be the opposite: apiResource with the extra information.

It would give the API room to grow with new properties for each type, and simplify API consumers for updating things like the slug or parent - replacing the whole publicResource or parent properties.