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
Would this asynchronous interaction expose any new resources, or involve existing ones (e.g. URI of a fedora resource, as defined via the Fedora HTTP API)? How do asynchronous and non-asynchronous aware clients interact with the resource?
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 this use case in a common pattern for asynchronous interactions?
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.
