A lightweight API for indexing metadata and links to existing derivatives into Avalon.
...
Bib import failure will result in a JSON response: {errors: ['Bib import failed', e.message]}, status: 422
admin/collections Anchor collections collections
...
Code | Description |
---|---|
200 | Okay. For GET, the relevant JSON will be contained in response body. For PUTS and POST response body will contain pid of created/updated item. |
201 | <Not used> Created |
202 | <Not used> Accepted, Queued |
400 | <Not used> Bad request |
401 | <Not used> Auth Failure. No token present in request header 'Avalon-Api-Key' |
403 | Forbidden. If valid Invalid token is not included in request header 'Avalon-Api-Key' |
404 | Resource Not Found. If object is not found for requested pid. |
405 | <Not used> Method Prohibited |
409 | <Not used> Conflict/Other Error. Conflict ex: pid in use |
422 | Processing failed. Response body will contain JSON has hash with :errors key pointing to a list of error message strings. |
Additional information for response included in JSON in the body as {status: Okay or ErrorCode, message: ""}
Open Issues:
- Should we be strict with CRUD? Yes, for now. Exception is PUTS and POST return effected item's pid.
- 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? Pagination is in place: :page and :per_page can be specified in request parameters.
- 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. For now GETs are protected by tokens.
...