Title (Goal) | As a repository manager, I want to expose a web service at a URI bound to a Fedora object |
Primary Actor | Repository Manager |
Scope | |
Level | |
Author | Aaron Birkland |
Story (A paragraph or two describing what happens) | My institution has developed a web application which provides a nifty visualization (html + js) for certain kinds of Fedora objects, as well as an XML representation of the same. To create the vizualization, my application reads a fedora object, queries a few indexes, does a few computations, and renders an appropriate representation based on the desired content-type. I would like to expose this web service at a URI /rest/path/to/object/viz:nifty for any object /path/to/object with an rdf:type of viz:Visualizable. I'd ideally like to wire my application to the viz:nifty URIs by creating or editing some sort of configuration file or fedora object, rather than compiling and deploying specialized code to do that. |
API Extension Architecture's role:
- Allow repository manager to bind path segment
viz:niftyto objects with rdf:type of viz:Visualizable - Allow the repository manager to specify the address of the web service that implements
viz:nifty - Route user's http requests from viz:nifty to the web service, and return its response
- Provide the identity of the relevant Fedora object to the web service when routing http request to it.
Web application's role:
- Respond to requests directed from
viz:nifty
Repository manager's role:
- Deploy web application
- Specify address of web application, rdf:type of relevant objects, and URI path segement (
viz:nifty)
Fedora's role:
- Respond to requests from the web application, if any.
2 Comments
Stefano Cossu
Is this something that you can achieve by using an Accept header instead of a custom path segment? Or do you need more flexibility than the one provided by specifying a mimetype?
A. Soroka
Even if you don't need that flexibility now, someone will. What Aaron Birkland is describing here is very similar to Fedora <4 CMA, and people who used that will be able to verify that mimetype isn't nearly enogh to distinguish, say, the human-targeted HTML display of a resource from the human-targeted HTML+JS visualization (as in Aaron's example) of that resource from the human-targeted script-generated HTML+JS editing display of that resource.