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.
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
Content Modeling
/rest/fcr:nodetypes
- GET /rest/fcr:nodetypes
- POST /rest/fcr:nodetypes
Warning |
---|
The request body format for updating nodetypes is in flux. For now, and in the immediate future, it uses JCR's CND syntax, but we'd prefer a provider-independent format. |
Code Block |
---|
GET /rest/fcr:nodetypes
get the RDFS serialization of the fcrepo4 content model
POST /rest/fcr:nodetypes (with Content-Type: text/cnd)
[fedora:custom-node-type] > [fedora:resource]
- fedora:thumbnail (string)
update the fcrepo4 content model using JCR CND declarations
|
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)
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 | ||||||
---|---|---|---|---|---|---|
|
- POST mints a new identifier at the given path