Use Case Evaluation

Web Resources and Interactions

The user interacts with Fedora resources, at their own native URIs, as usual.
The extension filters requests and responses to Fedora in order to inject signposting headers into the response on its way to the user

A GET or HEAD request is made to a Fedora resource
The extension has been configured to specify the http headers to be injected into the response
The data from which the header values will be derived is accessible to the extension

A camel route would be a logical implementation of the
Deployed in a layer serving as a reverse proxy, routing request through the extension is straightforward
Deployed in the same OSGI or servlet container as Fedora, the appropriate place to enact the extension may be a servlet filter

API-X must be able to identify requests to Fedora resources, and pass the request to the extension for such requests
API-X must route traffic to and from this extension via a filter pattern; invoking the extension as a filter on a request or response, then routing the filtered request or response to its destination
- Corollary: Used in a filter pattern, an extension implementation must not be required to perform request routing to a particular concrete destination (e.g. a Fedora repository).
API-X must be able to invoke extension implementation in a manner appropriate to the extension architecture's manner of deployment.
- In other words, a given extension should be depolyable into API-X if regardless of whether API-X itself is deployed as a separate service in a proxy pattern, or within the same servlet container as a running Fedora instance.

Allows the same extension to be deployed in two vastly different contexts (reverse proxy, or in same container as Fedora)
Provides the ability to transparently modify the representation of a Fedora resource in an existing Fedora repository