Call for comment

[Richard Rodgers]

Hey RESTafarians:

I've just completed a first pass of a REST API for mds (DSpace):

https://github.com/richardrodgers/mds/tree/master/webapi

It aims to be fairly complete, in the sense that one can do full CRUD on DSpace content objects, on authorization data (EPersons, Groups, Resource Policies),

and on registry data (Metadata schemas and fields, Bitstream formats).

Any comments on endpoint design, functional omissions, REST compliance, weirdness, etc very welcome.A few things I know that need to be added include entity list pagination.

I'll also post shortly a link to formal API docs, and later try to put up a site with some data where one can interact with it for real.

Thanks in advance for any feedback....

Richard

[Richard Rodgers]

Hey all:

As promised, I've now got formal API docs, in a good browsable/exercisable format at:

 

http://api-portal.anypoint.mulesoft.com/mit-libraries/api/mds-web-api

or just go to the 'front page' at:

http://api-portal.anypoint.mulesoft.com

and put 'mds Web' in the search box. Be sure to click the 'RAML Console' link on the left to get to the API.

This UI also allows you to hook up a backend, so that you can use the API directly. My next task is to stand up an mds instance

somewhere that can serve that function.

Thanks,

Richard

[Richard Rodgers]

Hey all:

Just one further update: I have stood up a cloud-hosted instance of mds and connected it to the API at Anypoint.

So if desired, you can interact with the REST API with real data. A few caveats/notes:

(1) I notice that the XML responses don't display very well in the Console (whereas the JSON ones do). On a future update,

I'll try to change the default to JSON (i.e. if you don't put in an Accept header) from XML.

(2) If the Anypoint UI is clumsy - you can of course directly use the API with curl, a browser, etc: The base URL is:

http://mds-demo.modrepo.org:8080/webapi

(3) I populated the repo with a teeny bit of content (a community, a collection, a few items). Please feel free to add your own content, epeople, etc

(at the moment, there is no auth required), but don't delete anything you didn't create, so it's in a reasonable state for others. I don't have any scripts like

those that run on dspace-demo that clear it out periodically.

Thanks a lot,

Richard

[Peter Dietz]

Hi Richard, 

I've been meaning to pick up on this, and give it a whirl.

Thus far, just poking around on the client side of things,.

key notes: 

/content is really the base of everything. 

To get your content (comm, coll, item) its

/content/<fullhandle>, such as /content/123456789/1

Then, to get info out of the content, you have to supply an action to the end of the URI. 

Actions are: collections, subCommunities, items, mdsets, media

Combined, to get the collections within a top community

/content/123456789/1/collections

You'll find Actions and more fully described in the RAML (RestApiMarkupLanguage) http://api-portal.anypoint.mulesoft.com/mit-libraries/api/mds-web-api/mds-webapi.raml

To help me get started digest this API, I'll made a new branch off the dspace-rest-play app I've been using. (i.e. Play! Framework app that makes a new UI based on consuming API).

To see the demo, start here.

http://dspace-mds-client.herokuapp.com/community/123456789/1

Thus far, it can parse a root community, its subcollection. The collection will show its items. And you can visit an Item. I haven't yet added Item bitstreams/metadata yet, but I think I've got the concept of how to consume this API. I'd say my initial feedback feeling is that I kind of liked being able to get lots of attributes (subColl, subComm, bitstreams, metadata) in a bigger request than to make subsequent calls. But it is fine I guess. And I haven't dug into the more advanced features of API yet.

Not too big of a refactor/diff to go from DSpace 4.0 REST to MDS-WebAPI

https://github.com/peterdietz/dspace-rest-play/commit/0167c02a7be15ac9af8f981b5c0597a08442c1bd

DSpaceRESTPlay @ MDS branch: https://github.com/peterdietz/dspace-rest-play/commits/mds

[Richard Rodgers]

Hi Peter:

Thanks for setting up the demo, and playing with it. On the specific observation about getting more attributes in one REST call, I agree that this approach is definitely more 'chatty'. I did it this way for a few specific reasons: pagination, and creation. In the pagination case, I was imagining cases where (for example) a community has a large number of collections *and* subcommunities. I couldn't think how to paginate the results if they were combined under one resource. What I mean is, if you want 'page2' of the resource, would that be page 2 of the collections, the subcommunities, or both? (And they could be of different sizes, etc). And for creation I wanted a resource URL that one could post to that was unambiguous: */collections would be only for collections. Otherwise, if one posts to the community itself, the entity body would have to indicate that that's a 'collection add' , rather than a 'subcommunity add', which seems a bit messy.

One could certainly imagine an implementation that split the difference (include all the attributes up to a threshold, otherwise, just return a new resource URL), but I thought that would complicate the API semantics a bit...

Anyway, thanks for the reactions. I'm certainly still 'tinkering' (prototyping) with this.

Richard

--
You received this message because you are subscribed to a topic in the Google Groups "DSpace REST" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dspace-rest/h71xmpeIjDw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dspace-rest...@googlegroups.com.
Visit this group at http://groups.google.com/group/dspace-rest.
For more options, visit https://groups.google.com/d/optout.