Closed tpluscode closed 3 years ago
I agree with the general idea - it was presented some time ago and it would solve a couple of the issues in this GH (i.e. #190 or #148).
The hydra:profile
sounds promising - the only thing to decide on what kind of IRI should be here. Shall it be some custom URI pointing to extension or URI pointing just to vocabulary in use.
Mayby a PREFER
header could be also used to negotiate possible profiles and extensions where possible
This should be resolved by PR #222 - closing
Introduce hydra vocabulary profiles or levels, i.e. level 0 and 1 where level 1 would be a default current hydra version and level 0 would be an alternative that does not imply a hydra:Resource is de-referencable (or event RDF based). This could also enable hydra for future profiles/levels using external schema vocabularies like SCHAL, OWL and non-rdf based ones.
Originally posted by @alien-mcl in https://github.com/HydraCG/Specifications/issues/216#issue-625154288
The third point however I find rather orthogonal. I'm not sure the "profiles" have anything to do with dereferencability of the API descriptions. More about the requirements from the client. I would see this as an open-ended set of "feature-packs" that a server may implement in addition to core. Here are some ideas:
expects
/returns
supportedClass
IANA Media types profile
multipart/form-data
body.Each profile would be free to define its specific processing rules.
The required changes would be to:
ApiDocumentation
to assert which profiles a server usesrdfs:range
statements of extension pointsSo as effect a server might announce itself as
Originally posted by @tpluscode in https://github.com/HydraCG/Specifications/issues/216#issuecomment-634486520