search

ProjectMirador / research-and-demos

Proofs of concept for Mirador 3
10 stars 8 forks source link

Adds in the ability to request v3 Presentation manifests using content negotiation #74

Closed mejackreed closed 5 years ago

mejackreed commented 5 years ago

Also sets up poc settings

christopher-johnson commented 5 years ago

I think that having to configure an api version in settings is too rigid. The client could just issue an Accept request for v3 by default.
The http spec says:

"If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation".

So, if the client gets a 406, then it should fall back to a standard v2 request. Otherwise, the response will be a v2.

The client deserializer (manifesto) should be able to handle v3 and v2 agnostically, or else provide a type check to provide versioned objects to consuming code.

mejackreed commented 5 years ago

Thanks for providing that context. I'm a little hesitant to make v3 the default until it becomes a released specification, especially since there are not many v3 content negotiation adoptions at the moment.

Maybe this config can go away once v3 adoption becomes more common?

christopher-johnson commented 5 years ago

maybe. but on the other hand, I think it would be useful to provide a conneg handler algorithm for unsupported v3 endpoints, as it is very unlikely that everyone will be on v3, even years from now. So, supporting v3 would not be a catch all, but rather simply a preferred option.

aeschylus commented 5 years ago

I like the idea of being able to set or update the entire config through actions. This wasn't really possible during runtime in Mirador 2, but our current set up makes this theoretically easy. Can we do that in a separate PR and talk more tomorrow about the manifestFetcher?

I have some questions about the fetcher and may be lacking some context. My first take is that I don't like having to somehow know the version of the manifest before requesting it, and having to pass that into the action. I also don't like that it's an object that has to be instantiated. In practice, is it acting as a function that configures the request?

mejackreed commented 5 years ago

Closing this for now. In POC session 12/12/2018 discussed this and alternatives. Config approach split out to #81