This page describes a potential set of questions to help evaluate use cases, present them in a clear and uniform way, and distill into requirements. The goal is to explore possible ways in which a common pattern for asynchronous interactions can be used to address each use case as concretely as possible, but falling short of providing a true specification or extension design.
Web Resources and Interactions
What web resources (URIs, patterns) are relevant to this particular API Extension? Would this extension expose any new resources, or involve existing ones (e.g. URI of a fedora resource, as defined via the Fedora HTTP API)? How does the user interact with the resource, and how is the extension involved in that interaction?
Preconditions
Under what conditions should the API extension architecture expose a URI, or invoke this extension? The current understanding of 'invoke' means "direct an HTTP request or response to an extension for processing." If this particular use case uses 'invoke' in a different way, please define.
Examples of preconditions include:
- Extension is invoked when a request is made to any repository resource.
- Extension is invoked when a request to any resource contains certain content (e.g. is a POST, or contains a particular HTTP header)
- URIs with pattern /path/to/object/ext:myExtension are exposed whenever a given Fedora object has an
rdf:typeofmyns:myType - Extension is invoked when a request is made to a web resource (URI) exposed by the API-X.
Deployment or Implementation notes
Are there any deployment or implementation-related details that may be relevant?
Examples include:
- We anticipate implementing this use case using the API Extension Architecture
- This pattern uses features of modeshape, and inherently needs to be installed with Fedora
- Implemented as camel routes that can be deployed into any osgi container
Proposed Requirements
What requirements may this use case place on the repository container, core Fedora API, or API extension architecture?
Value Proposition
What do you see as a potential value proposition of the API extension architecture for this use case above and beyond, say, deploying web service somewhere and having clients point to its URI, or compiling an extension into Fedora using webapp+, or deploying into an OSGi container beside Fedora?
Examples include:
- The API-X defines a single public URI for this service, which abstracts away the details of its real location on my backend infrastructure, allowing the implementing web service to be easily re-located.
- The API-X allows the presence of this service to be discovered by clients
- The API-X provides a convenient way to integrate this service as a filter for all requests.
- The API-X provides a convenient way to distribute and deploy the extension so that others can easily use or evaluate it.
