Possible future support for compliance levels/profiles for the Fedora API?

[DiegoPino]

Hi,

I mentioned this briefly (or not that briefly for those who know me) to @dbernstein during OR2018.

There is some desire coming from me to make "Esmero", our Server-less Fedora(s) implementation,or at least one of its exposed APIs, Fedora API compliant, but also be able to decide, on an implementation level, to what extend i want that to happen.

Reason is not every Esmero deployment needs to be exposed to the world (by WebACL?) or even accept multiple RDF serializations (We like JSON-LD exclusively), so we can and want for the sake of Client awareness tell the client we are Fedora API compliant, but not all ways of interacting are implemented. All this under something that is not anarchy and chaos coming from us.

This idea is of course not new, not mine, and is borrowed from IIIF, where e.g image API actually defines profiles (compliance levels) that allow clients to actually adapt or even decide on the fly what-how they can interact with certain services and also make some service providers slimmer, but honestly slimmer.

See http://iiif.io/api/image/2/level2.json

{
  "@context": "http://iiif.io/api/image/2/context.json",
  "@id": "http://iiif.io/api/image/2/level2.json",
  "@type": "iiif:ImageProfile",

  "formats": ["jpg", "png"],
  "qualities": ["default", "bitonal"],
  "supports": [
    "baseUriRedirect",
    "cors",
    "jsonldMediaType",
    "profileLinkHeader",
    "regionByPct",
    "regionByPx",
    "rotationBy90s",
    "sizeByWhListed",
    "sizeByConfinedWh",
    "sizeByDistortedWh",
    "sizeByForcedWh",
    "sizeByH",
    "sizeByPct",
    "sizeByW",
    "sizeByWh"
  ]
}

versus the simpler http://iiif.io/api/image/2/level1.json

{
  "@context": "http://iiif.io/api/image/2/context.json",
  "@id": "http://iiif.io/api/image/2/level1.json",
  "@type": "iiif:ImageProfile",

  "formats": ["jpg"],
  "qualities": ["default"],
  "supports": [
    "sizeByWhListed",
    "baseUriRedirect",
    "cors",
    "jsonldMediaType",
    "regionByPx",
    "sizeByH",
    "sizeByPct",
    "sizeByW"
  ]
}

By allowing something like this there are at least a few community benefits:

1. The API specification becomes machine computable.
2. More specific implementations can become Fedora API compliant.
3. Being compliant can be progressive and scale from one level to another
4. Clients can become smarter.

Could this be discussed for a version 2 of the API?

Thanks

[zimeon]

I think a level-of-compliance or the more general notion of features-supported would be a good way to explore how allow greater flexibility of server implementation in a compatible but limited way. It might also be a good way to bring things currently deemed too demanding into-the-fold as higher level features (e.g. atomic operations, single request fixity checks). So 👍 to talking about such approaches in any v2 effort.

[awoods]

Agreed. This seems like a potentially constructive next step. Thanks, @DiegoPino .

[bseeger]

I'm not a spec writer, but I really like this idea and want to express support for it. I wonder if we could do something less programatic and with documentation sooner (a compliance matrix?) rather then later, and then create some more formal protocol like IIIF has later on?

[awoods]

Deferring until v2 of specification per: https://wiki.duraspace.org/display/FF/2018-08-29+-+API+Spec+Meeting