...
Web Resources and Interactions
What web resources (URIs, patterns) are relevant to this particular API Extension? Would this extension 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 does the user do asynchronous and non-asynchronous aware clients 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.
...
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 Fedorathis 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.
...