CSS Stylesheet |
---|
h3 { background-color: #eee; padding: 0.6em; }
#content .code { margin-left: 2.5em!important; background-color: #fafafa!important; }
.pdl .syntaxhighlighter table td.code .container, .syntaxhighlighter .line.alt2, .syntaxhighlighter .line.alt1 { background-color: #fafafa!important; } |
Table of Contents
Expand | |
---|---|
|
Overview
Introduction
Excerpt |
---|
The Fedora 4 HTTP API is generally a RESTful API. HTTP methods like GET, PUT, POST and DELETE are implemented on most resource paths. The API also relies heavily on content negotiation to deliver context-appropriate responses, and a HATEOAS-driven text/html response (providing a decent GUI experience on top of the repository). |
The Fedora 4 RDF-based responses may be serialized as:
- application/ld+json
- application/n-triples
- application/rdf+xml
- text/n3 (or text/rdf+n3)
- text/plain
- text/turtle (or application/x-turtle)
The text/html response also includes embedded RDFa markup.
Fedora 4 implements the Linked Data Platform 1.0 Architecture, which:
[...] describes the use of HTTP for accessing, updating, creating and deleting resources from servers that expose their resources as Linked Data. It provides clarifications and extensions of the rules of Linked Data [LINKED-DATA]:
- Use URIs as names for things
- Use HTTP URIs so that people can look up those names
- When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
- Include links to other URIs, so that they can discover more things
Endpoints
Resources
Repository objects can be loosely divided into two classes of resources:
- Containers ("fedora:Container"), containing RDF properties and 0 or more child resources
- Binaries, containing any binary payload (roughly corresponding to Fedora 3 datastreams)
Containers
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|
Export and Import
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|
Versioning
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|
Services
Access Roles
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|
Backup and Restore
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|
Fixity
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|
Node Types
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|
Transactions
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|
Transform
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|
Table of Contents |
---|
Some Definitions
jcr - java content repository http://www.day.com/day/en/products/jcr.html; used by fcrepo4 for storing object structure and content
node - a jcr object; it may be a fedora datastream or object.
mixin - a jcr concept we're leaking downstream. for all downstream consumers need to care, this is a simple 'tag' with a couple possible values: fedora:object, fedora:datastream.
path - a (potentially) hierarchical path to a jcr node (either an object or datastream)
namespace - JCR nodes MAY have a namespace component to their identifier. Unlike fcrepo 3.x, a namespace prefix must be explicitly registered before it can be used. (I assume we can create nodes with the fully-qualified namespace without registering it?)
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
/rest/fcr:namespaces/{prefix} (with a request body for the URI the namespace prefix should resolve to)
- POST create the namespace prefix
/rest/fcr:nextPID
- POST mints an ID
Nodes
/rest/{path}
- GET lists children, with optional filter by mixin
- POST create a new node of QueryParam "mixin" at {path}
- PUT mutate the object at {path}
- DELETE remove the object at {path}
Code Block |
---|
GET /rest/
list the top-level objects in the repository
GET /rest/objects/sufia:123456789
list the children under /objects/sufia:123456789, which may include properties(?), datastreams or additional fedora objects/collections
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 children under /some-other-object-living-at-jcr-root, which may include properties(?), datastreams or additional fedora objects/collections
GET /rest/objects/sufia:123456789?mixin=fedora:datastream
only list the `fedora:datastreams` that are children of /objects/sufia:123456789
POST /rest/objects/islandora:xyzasdf with request body
(I seem to remember something about a JSON/XML serialization of "profile" properties...)
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. (Will this create all the intermediate nodes? do I need to do this manually?)
PUT /rest/objects/sufia:123456789
(not sure what this implies.. manipulating properties of the node?)
DELETE /rest/objects/sufia:123456789
Delete the node at /objects/sufia:123456789 |
/rest/{path}/fcr:new
- POST create a new child of QueryParam "mixin" under {path}
Code Block |
---|
POST /rest/objects/fcr:new
create a new child object with an automatically generated unique identifier
POST /rest/objects/sufia:123456789?mixin=fedora:datastream
create a new child datastream for /objects/sufia:123456789 with an automatically generated unique identifier |
/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 JCR node there..)
PATCH /rest/objects/sufia:123456789/THUMBNAIL/fcr:content
(I assume PATCH will work.. that'd be pretty cool) |
/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 |
Describe
/rest/{path}/fcr:describe
- GET profile or description [repo describe at root, profiles by type]
- POST unsupported?
- PUT unsupported?
- DELETE unsupported?
Code Block |
---|
GET /rest/fcr:describe
describe the fcrepo4 repository
GET /rest/objects/sufia:123456789/fcr:describe
describe the object /objects/sufia:123456789 (equivalent to the fcrepo 3.x "object profile")
GET /rest/objects/sufia:123456789/content/fcr:describe
describe the datastream /objects/sufia:123456789/content (equivalent to the fcrepo 3.x "datastream profile")
GET /rest/some/arbitrary/jcr:path/to/sufia:123456789/the/tree/continues/fcr:describe
describe the node at /some/arbitrary/jcr:path/to/sufia:123456789/the/tree/continues (equivalent to the fcrepo3.x "datastream profile").
If the node resolves to a JCR "nt:file", we treat it as a datastream. Else, an object (or collection)
|
Versioning
/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
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' |
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 |
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