mitlibraries / backrest Goto Github PK

The URLs for logos are being constructed like regular bitstreams:

/bitstream/handle/1721.1/234/filename?sequence=1

but this is incorrect - there is a special syntax for them:

/bitstream/id/dbid/filename?sequence=-1

Error occurs when attempting to look up handle as though it were an item

Currently, server errors occur if the client does not set an Accept header to one of a few expected values (application/xml or application/json). The API should be more flexible and provide a default serialization in other cases (missing Accept or value of '/'). JSON seems a reasonable choice.

Behaviour of expand parameter for /items/{itemId} differs from DSpace 5.4:

1. name element is only populated if expand=metadata is used (DSpace 5.4 populates always)
2. ?expand=all fails
3. ?expand=parentCommunityList fails

Quick test from an external account...to be closed...

item/{itemId}?expand=metadata returns duplicate metadata elements

Create docker image for easy deployment

The \status call returns an incorrectly named <ok> element - it should be <okay>. Same issue also exists with json format.

Service currently listens on 0.0.0.0 (all/any IP addresses). Should be able to restrict to specified address/host.

Each major version of DSpace modifies the database schema in potentially API-affecting ways. One simple example is the introduction of item counts in collections. Since that is a reported field in the API, if backrest were not aware of the version of DSpace it was running, the query would cause an exception. Solution would be to query a Postgres system table at start up, and version-sensitize the DB queries.

The response content (at least for certain endpoints) is quite static and therefore amenable to caching, which would avoid both the database hit(s) and the marshalling cost of recreating with each request. A simple cache where the key is a combination of the requested URL and the Accept header media type, and the value the XML or JSON document response (NB: bitstreams would not be cached) should suffice.

Currently, only XML supported

When obtaining bitstream policy data using XML format, DSpace 5.4 REST API uses an element 'resourcePolicies'. Backrest returns a 'resourcepolicy' element, which doesn't match the same xpath...
(This looks like an inconsistency in the DSpace API, given that it returns 'resourcepolicy' elements with 'resourcePolicies', but Backrest must reflect the same behaviour as the 'official' api.)

Can get them to succeed for certain values of limit & offset parameters, but basically broken

Noticed just a minute too late.

Concurrent modification exception

Not sure how one can create a logo without a name, but since it (name) is not required for resolution (the bitstream primary key is in the URL), should handle more gracefully

to replicate the behavior of the DSpace rest API. POSTS to /login & /logout do what they say, and GET to /status returns session & eperson info.

Has similar semantics to 'mama' endpoint, but is a POST rather than a GET, and returns Item records, rather than selected fields. Requested to support a use-case in the Symplectic Elements integration.

When requesting hierarchical parent lists, duplicates are not filtered out (common parents)

The response for this call looks inconsistent with DSpace 5.4 REST API (see
Bitstreams policy sample.txt
):

1. schema looks different to DSpace 5.4 data (rpName, rpDescription?)
2. unclear about values for epersonId, groupId
3. capitalisation for action, rpType values?