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

Overview

Introduction

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]:

1. Use URIs as names for things
2. Use HTTP URIs so that people can look up those names
3. When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
4. 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

Export and Import

Versioning

Services

Access Roles

Backup and Restore

Fixity

Node Types

Transactions

Transform

/rest/fcr:sitemap
/rest/fcr:search
/rest/fcr:namespaces

/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}

GET /rest/
  list the top-level objects in the repository
 
GET /rest/sufia:123456789
  list the children under sufia:123456789, which may include properties(?), datastreams or additional fedora objects/collections
 
GET /rest/sufia:123456789?mixin=fedora:datastreams
  only list the `fedora:datastreams` that are children of sufia:123456789
 
POST /rest/islandora:xyzasdf with request body
  (I seem to remember something about a JSON/XML serialization of "profile" properties...)
 
POST /rest/islandora:xyzasdf?mixin=fedora:object
  create a new fedora object at islandora:xyzasdf
 
POST /rest/islandora:xyzasdf/an/arbitrary/hierarchy/to/an/islandora:datastream?mixin=fedora:datastream
  create a new datastream at 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/sufia:123456789
  (not sure what this implies.. manipulating properties of the node?)
 
DELETE /rest/sufia:123456789
  Delete the node at sufia:123456789

Describe

/rest/{path}/fcr:describe
- GET profile or description [repo describe at root, profiles by type]
- POST unsupported?
- PUT unsupported?
- DELETE unsupported?

GET /rest/fcr:describe
  describe the fcrepo4 repository

GET /rest/sufia:123456789/fcr:describe
  describe the object sufia:123456789 (equivalent to the fcrepo 3.x "object profile") 

GET /rest/sufia:123456789/content/fcr:describe
  describe the datastream 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 /rest/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)

Other stuff

/rest/{path}/fcr:new
- POST create a new child of QueryParam "mixin" under {path}

/rest/{path}/fcr:new/fcr:content
- POST create a new nt:file under {path} with a binary value of the request entity

/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}

/rest/{path}/fcr:datastreams is batch DS operations
- GET
- POST
- DELETE

/rest/{path}/fcr:fixity
- GET get the fixity report for the nt:file at {path}

/rest/{path}/fcr:versions
- GET the version history of the nt:file or the nt:folder (as appropriate) at {path}