Old Release

This documentation covers an old version of Fedora. Looking for another version? See all documentation.

Much of the functionality that is exposed through the RESTful HTTP API is also available using an HTML user interface interpreted by your favorite web browser.  Whether your request for particular HTTP API endpoints results in an HTML UI or more machine-readable formats is based on content negotiation headers.  This tour walks you through the major user interface components when accessing the HTTP API through a web browser.

Home Page

When you access the root path of the RESTful HTTP API you are presented with a rendering of the root level of your Fedora repository.

From here you can:

  • Create new Resources (Containers or Binaries)
  • Inspect the properties of Resources. 
  • Update the properties of Resources.
  • Navigate the Repository Hierarchy of Resources.
  • Import/Export Resources.
  • Start Transactions.

The user interface is divided into regions.

  • Navigation bar (top)
  • Resource information and navigation (center left)
  • Optional resource actions (center right)

Navigation Bar

The navigation bar, which appears at the top of each page, includes links to the following:

Resource Information

Information about the resource requested is displayed below the navigation bar, filling the left two thirds of interface.


1 Object Title 

If a title (either http://www.w3.org/2000/01/rdf-schema#label or http://purl.org/dc/elements/1.1/title) is available, it is displayed here. If no title has been assigned, the resource URI is displayed in this location.

2 Object Path 

Fedora 4 is different from Fedora 3 in that there is an innate tree hierarchy to the repository rather than a flat structure. The path (list of ancestors) for the viewed resource is presented below the object title. Performance is expected to be better with a deeper hierarchy with fewer items per level as opposed to a shallow hierarchy where each level has a larger number of siblings. The automatic ID (and path) generated is meant to optimize performance, but you may use your own organizational strategy when creating resources.

In this particular example, the container was created with a fully qualified name including a namespace and local name (separated by a colon). Fedora 4 does not require (nor recommend) that identifiers have namespaces.

3 Featured Properties

Very basic metadata such as the UUID and modification/creation times and users are presented below the resource path.

4 Children

Any children that the container has will be listed and linked here. Like the parent containter, if a child resource has recognized title metadata, the title will be presented here rather than its URI.

5 All Resource Properties 

All properties of the resource are presented here. Hover your mouse over the namespace prefix to see the full namespace.

6 Other Resources 

A subset of properties from the parent resource. Click on the gray box to expand the list of properties or the label text to view that resource directly.



On the right side of each page is a list of actions that can be performed for the resource at the current path.

These may include:

Create New Child Resource

From the homepage or any container page a form exists that lets you create a new container or binary that will be the child of the current container.

Download/Update Content

When viewing a NonRdfSourceDescription with binary content, click the large green button to download that content. You can also update the description of the binary using the form.

Update Properties

When viewing a resource, you can add or delete properties using the "Update Properties" form.

Delete Resource

You can delete the resource you are currently viewing by clicking the red "Delete" button.


When viewing a resource, you can export it using the "Export as..." button. In the case of containers, you can also import a resource using the "Import" form.



  • No labels


  1. We have an application ingesting records into fedora in our staging environment.  After the ingest has been validated and approved, we need to migrate the ingest into the production.  We would like a way to find the last changes in fedora.ispn_entry_fedorarepository database so we do not have to migrate the whole database, which is very large.   For the fedora non-rdf resources which are saved in fedora data files, we use robocopy to migrate staging to production.  We would like to migrate the delta just as we do for fedora database.  Is there anyway to do that?




    1. You may get a better response by posting the question to fedora-tech@googlegroups.com.