Title (Goal)	As a developer, I would like to write an extension to add http 'Link' headers to Fedora's REST API responses
Primary Actor	Developer
Scope
Level
Author	Aaron Birkland
Story (A paragraph or two describing what happens)	As a developer using Fedora as a repository for publication data, I am interested in exploring signposting as a way to label the links between scholarly resources using http headers. As this effort is still in its early stage, I'd like to do some experimentation, so I'd like to write an API Extension module that will add specific http headers to responses for certain Fedora resources. As a concrete example, we'd initially like to add a rel='canonical' link header pointing to the DOI of record, as shown here.

API Extension Architecture's role:

Provide a means of filtering/enhancing the representation of existing Fedora objects in an extension. In this case, that means adding a link header to the HTTP response.

Developer's role:

Fedora's role:

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