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:
- Create and deploy an API Extension module that implements the desired headers.
Fedora's role:
- Provide its usual representation of a given resource
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
Preconditions
- 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
Deployment or Implementation notes
- 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
Proposed Requirements
- 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.
API-X Value Proposition
- 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
2 Comments
Elliot Metsger
So this extension would need to have access to the Fedora resource being served (perhaps the canonical DOI of record is recorded in the resource itself), and the response object.
It would need to be able to select what resource responses to operate on.
Aaron Birkland
Yes. I'm thinking that, at minimum, this extension would need access to the HTTP response from Fedora in order to mutate it (add headers). The necessary information to do so could possibly be in the response body itself if the request is one that returns a representation of a Fedora object.