Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

A lightweight API for indexing metadata and links to existing derivatives into Avalon.  
Version
Date
Description
0.1
13 October 2015
Initial Draft

Table of Contents 

items

GET items/:pid Retrieves information on the item

POST items/ Creates an item

PUTS items/:pid Updates an item 

JSON:

{mods: {mods converted to JSON}, collection: collection_id, derivatives: [location_of_derivatives], private: <Boolean, default=false> }

GET returns the mods (or otherwise specified subset of metadata), POST requires everything to be able to create a new item, PUTS updates just the supplied JSON.  POST and PUT fail if there is not: mods, a unique pid for the object, valid collection_id, mods, and derivatives.  If private is not specified, it is assumed to be public.  

collections

GET collections/ Retrieves a list of all collections

GET collections/:pid Retrieves information on the collection

GET collections/:pid/items Retrieves a list of all items in collection :pid

POST collections/:pid Creates a collection

PUTS collections/:pid Updates a collection

response codes:

CodeDescription
200

Okay

201

Created

202

Accepted, Queued

400

Bad request

401

Auth Failure

403

Forbidden

404

Resource Not Found

405

Method Prohibited

409

Conflict/Other Error

Conflict ex: pid in use

Additional information for response included in JSON in the body as {status: Okay or ErrorCode, message: ""}

Open Issues:

  • Should we be strict with CRUD?  E.g. If an item exists and a post command, versus put, is issued should it update or return a code existing the item already exists?  Also if a PUT is attempted on an item that doesn't exist should we fail or just create the item?  Specifically when a user puts and there is no item to update, do they care?
  • Regarding the 202 Code, this may not be needed, but I put in place in the event we have to accept API requests and wait to go test streaming (make sure the derivatives are there).  This is a worst case if our file storage is too slow (which would be really bad of course).  
  • Should we let GET items/ return a list of all items?  List would be massive.
  • Additionally allow GET to be called without an API key/IP restrictions (public).  Would be useful for third parties who want data feeds from us.

 

  • No labels