Table of Contents |
---|
The Fedora 4 REST API is generally a RESTful API. HTTP methods like GET, PUT, POST and DELETE are implemented on most resource paths. The REST API also relies heavily on content negotiation to deliver context-appropriate responses, and a HATEOAS-driven text/html response (providing a decent admin GUI experience on top of the repository).
The Fedora 4 RDF-based responses may be serialized as:
- application/n3 (or text/rdf+n3 or text/n3)
- text/turtle
- application/n-triples
- text/trig
- application/xml+rdf
- application/json+rdf
- application/n-quads
The text/html response also includes embedded RDFa markup.
Objects
Retrieve or manipulate a node in the Fedora 4 repository.
/rest/{path}
- GET describe object
- POST create a new node of QueryParam "mixin" at {path}
- POST (with an application/sparql-update payload)
- PUT mutate the object at {path}
- DELETE remove the object at {path}
Code Block |
---|
GET /rest/ list the top-level objects in the repository POST /rest/fcr:properties with an application/sparql-update request body @prefix dc: <http://purl/somewhere/something/1.1> INSERT { <info:fedora:/objects/islandora:xyzasdf> <dc:title> "My title" } WHERE {} GET /rest/objects/sufia:123456789 list the properties of this node GET /rest/some-other-object-living-at-jcr-root there's nothing special about /objects, it's just another part of the path to an object. List the object properties POST /rest/objects/islandora:xyzasdf with an application/sparql-update request body @prefix dc: <http://purl/somewhere/something/1.1> INSERT { <info:fedora:/objects/islandora:xyzasdf> <dc:title> "My title" } WHERE {} create a new object at /objects/islandora:xyzasdf and run the SPARQL-Update query against the resulting triples POST /rest/objects/islandora:xyzasdf with a turtle/n3/n-triples/etc request body <info:fedora:/objects/islandora:xyzasdf> <http://purl/somewhere/something/1.1/title> "My title" create a new object at /objects/islandora:xyzasdf with the provided triples POST /rest/objects/islandora:xyzasdf?mixin=fedora:object create a new fedora object at /objects/islandora:xyzasdf POST /rest/objects/islandora:xyzasdf/an/arbitrary/hierarchy/to/an/islandora:datastream?mixin=fedora:datastream create a new datastream at /objects/islandora:xyzasdf/an/arbitrary/hierarchy/to/an/islandora:datastream in the JCR tree. (This will create all the intermediate nodes) POST /rest/objects/islandora:xyzasdf (where /rest/objects/islandora:xyzasdf already exists) with an optional application/sparql-update or turtle/n3/n-triples/etc body @prefix dc: <http://purl/somewhere/something/1.1> INSERT { <> <dc:title> "My title" } WHERE {} add a child object (with a repository-minted name, creating /objects/islandora:xyzasdf/some-uuid-pattern) to islandora:xyzasdf and run the SPARQL-Query against the resulting object POST /rest/objects/islandora:xyzasdf (where /rest/objects/islandora:xyzasdf already exists) -> Slug: 123 add a child object with the name 123 (creating /objects/islandora:xyzasdf/123) and run the SPARQL-Query against the resulting object PUT /rest/objects/sufia:123456789 with an RDF request body @prefix dc: <http://purl/somewhere/something/1.1> <info:fedora/rest/objects/sufia:123456789> dc:title "xyz" replace all triples for sufia:123456789 with the triples in the request body (note that some triples are fcrepo-managed (e.g. the fedora-internal namespace) and cannot be modified in this way PATCH /rest/objects/sufia:123456789 with an application/sparql-update request body @prefix dc: <http://purl/somewhere/something/1.1> INSERT { <info:fedora:/objects/islandora:xyzasdf> <dc:title> "My title" } WHERE {} "patch" the properties of the sufia:123456789 object by executing the given query DELETE /rest/objects/sufia:123456789 Delete the node at /objects/sufia:123456789 COPY /rest/objects/sufia:123456789 with headers: Destination: http://path/to/repository/rest/objects/sufia:987654321 Copy the object (and subtree) at /objects/sufia:123456789 to the provided Destination path MOVE /rest/objects/sufia:123456789 with headers: Destination: http://path/to/repository/rest/objects/sufia:987654321 Move the object (and subtree) at /objects/sufia:123456789 to the provided Destination path |
Binary Content
/rest/{path}/ fcr:content
- GET the bytes from {path}/ jcr:content/jcr:data
- POST create a new nt:file at {path} with a binary value of the request entity
- PUT mutate the binary value of the nt:file at {path}
- DELETE remove the jcr:content child from the node at {path}
Code Block |
---|
GET /rest/objects/sufia:123456789/DS1/fcr:content get the binary content of DS1 POST /rest/objects/sufia:123456789/THUMBNAIL/fcr:content (with a request body) add the binary content from the request body to THUMBNAIL PUT /rest/objects/sufia:123456789/THUMBNAIL/fcr:content (with a request body) update the binary content in the THUMBNAIL DELETE /rest/objects/sufia:123456789/THUMBNAIL/fcr:content remove the binary content from THUMBNAIL (but leave the object /objects/sufia:123456789/THUMBNAIL there) |
/rest/{path}/fcr:new/fcr:content
- POST create a new nt:file under {path} with a binary value of the request entity
Code Block |
---|
POST /rest/objects/sufia:123456789/fcr:new/fcr:content create a new child datastream (with an automatically generated unique identifier) with the content provided by the request body |
Datastream Batch Operations
/rest/{path}/fcr:datastreams is only for batch DS operations
- GET
- POST
- DELETE
Code Block |
---|
GET /rest/objects/sufia:123456789/fcr:datastreams?dsid=DC&dsid=RELS-EXT&dsid=CONTENT_METADATA receive a multipart/mixed response of the 3 named datastreams under /objects/sufia:123456789 POST /rest/objects/sufia:123456789/fcr:datastreams (with a multipart body) create any number of datastreams under /objects/sufia:123456789 DELETE /rest/objects/sufia:123456789/fcr:datastreams?dsid=THUMBNAIL&dsid=CONTENT delete the two named datastreams under /objects/sufia:123456789 |
Fixity
/rest/{path}/fcr:fixity
- GET get the fixity report for the nt:file at {path}
Code Block |
---|
GET /rest/objects/sufia:123456789/THUMBNAIL/fcr:fixity retrieve the fixity report for the /objects/sufia:123456789/THUMBNAIL node |
Versioning
Warning |
---|
Versioning is not fully implemented in the Fedora 4 alpha |
/rest/{path}/fcr:versions
- GET the version history of the nt:file or the nt:folder (as appropriate) at {path}
Code Block |
---|
GET /rest/objects/sufia:123456789/fcr:versions get the version history of /objects/sufia:123456789 fedora object (not sure what the response looks like, though) GET /rest/objects/sufia:123456789/THUMBNAIL/fcr:versions get the version history of the THUMBNAIL datastream POST /rest/objects/sufia:123456789/THUMBNAIL/fcr:versions/XYZ tag the current verison of /objects/sufia:123456789/THUMBNAIL with the version label XYZ GET /rest/objects/sufia:123456789/THUMBNAIL/fcr:content?version=XYZ get the jcr:content@jcr:data of /objects/sufia:123456789/THUMBNAIL with version id 'XYZ' GET /rest/objects/sufia:123456789/fcr:describe?version=XYZ get the profile/description of /objects/sufia:123456789 with version id 'XYZ' |
Export
/rest/{path}/fcr:export?format={format}
- GET an export of the (tree?) under the \{path\}
/rest/{path}/fcr:import?format={format}
- POST an export and it will be deserialized at {path}
Code Block |
---|
GET /rest/objects/sufia:123456789/fcr:export retrieve a JCR/XML export of the content under /objects/sufia:123456789 POST /rest/objects/fcr:import with the request body retrieved as above add sufia:123456789 to the tree at /objects, with all its properties, child nodes, etc POST /rest/fcr:import and this works too |
Transactions
/rest/fcr:tx
- POST create a new transaction session
/rest/{txid}/fcr:tx/
- GET the status of a transaction
/rest/{txid}/fcr:tx/fcr:commit
- POST commit the transaction
/rest/ {txid}/ fcr:tx/fcr:rollback
- POST abort the transaction
Code Block |
---|
POST /rest/fcr:tx the Location header sends you to the repository scoped by the transaction you requested (e.g. Location: /rest/tx:123456) POST /rest/tx:123456/fcr:new you can use that transaction ID at the beginning of (most) requests to execute that action within the context of the transaction POST /rest/tx:123456/fcr:tx/fcr:commit and then save the transaction. Any operations you made within the scope of the transaction will be applied together, meaning if any of them fail, the whole transaction will fail. POST /rest/tx:123456/fcr:tx/fcr:rollback roll it back and forget it ever happened |
Workspaces
Warning |
---|
The Fedora 4 workspace implementation is in heavy flux. |
/rest/fcr:workspaces
- GET /rest/fcr:workspaces/{workspace path}
- POST /rest/fcr:workspaces/{workspace path}
Code Block |
---|
POST /rest/fcr:workspaces/abc create the workspace "abc" GET /rest/workspace:abc/{path/to/object} you can use the workspace identifier at the beginning of (most) requests, just like transactions |
Relationships
See this fcrepo3 discussion: Supporting the Semantic Web and Linked Data
ModeShape REST API: https://docs.jboss.org/author/display/MODE/REST+Service+3.x#RESTService3.x-5.Updateanodeoraproperty
External-ish services
/rest/fcr:sitemap
- GET retrieve a sitemap of all the "fedora:object" in the repository (wrapped as a sitemap index, pointing to other sitemaps..)
/rest/fcr:search
- GET a basic field search (similar to fcrepo 3.x) that exposes the Modeshape index (somehow.)
/rest/ fcr:namespaces
- GET list the registered namespaces
- POST (with a sparql update payload)
/rest/{path/to/object}/fcr:pid
- POST mints a new identifier at the given path