Hi all,
Reinhard and I have made some progress on a prototype that we hope follows some of the current best practices for REST API design (in particular, "intent driven design").
You can mess around with the prototype here: http://50.116.59.51:8080/api/docs/v2/index.html
Hopefully the documentation should be pretty clear -- our hope was to make it very easy to try out the API through this interactive/self-documenting UI (courtesy of swagger).
Features:
Behind the scenes we're currently using Jersey + Solr for these read-only endpoints. While we're more focused on the interface of the API right now, using SOLR under the hood has the advantage of making it nice and fast!
Here's an example of a javascript widget using the API (on real DASH data): http://50.116.59.51:8080/api/widgets/paging.html
Below is our initial stab at a schema. Is it missing anything critical? Is it too verbose? Is it simple and clear enough to a developer who knows nothing about DSpace and its database/table terminology? If we can agree on a common schema and REST behavior, theoretically institutions could implement a DSpace REST API in any framework they see fit. In any case, it would be nice to have the desired API interface drive implementation decisions rather than the other way around.
Very much looking forward to your feedback!
"Community":{ "id":"Community", "properties":{ "id":{ "type":"int" }, "description":{ "type":"string" }, "name":{ "type":"string" }, "url":{ "type":"string" } } }, "Collection":{ "id":"Collection", "properties":{ "id":{ "type":"int" }, "owningCollection":{ "type":"boolean" }, "description":{ "type":"string" }, "name":{ "type":"string" }, "url":{ "type":"string" } } }, "File":{ "id":"File", "properties":{ "id":{ "type":"int" }, "name":{ "type":"string" }, "format":{ "type":"string" }, "url":{ "type":"string" }, "size":{ "type":"long" } } }, "Author":{ "id":"author", "properties":{ "id":{ "type":"string" }, "authority":{ "type":"string" }, "orcid":{ "type":"string" }, "givenNames":{ "type":"string" }, "email":{ "type":"string" }, "name":{ "type":"string" }, "surname":{ "type":"string" }, "affiliation":{ "type":"string" }, "type":{ "type":"string" }, "href":{ "type":"string" } } }, "Works":{ "id":"Works", "properties":{ "communities":{ "items":{ "$ref":"Community" }, "type":"Array" }, "handle":{ "type":"string" }, "depositingAuthor":{ "type":"string" }, "issn":{ "items":{ "type":"string" }, "type":"Array" }, "subjects":{ "items":{ "type":"string" }, "type":"Array" }, "type":{ "type":"string" }, "lang":{ "type":"string" }, "version":{ "type":"string" }, "publisher":{ "type":"string" }, "journal":{ "type":"string" }, "id":{ "type":"int" }, "authors":{ "items":{ "$ref":"author" }, "type":"Array" }, "title":{ "type":"string" }, "otherVersions":{ "items":{ "type":"string" }, "type":"Array" }, "isbn":{ "type":"string" }, "pubYear":{ "type":"string" }, "license":{ "type":"string" }, "href":{ "type":"string" }, "publisherUrl":{ "type":"string" }, "collections":{ "items":{ "$ref":"Collection" }, "type":"Array" }, "abstract":{ "type":"string" }, "citation":{ "type":"string" }, "files":{ "items":{ "$ref":"File" }, "type":"Array" }, "lastModified":{ "type":"string" }, "url":{ "type":"string" }, "dateAccessioned":{ "type":"string" }, "school":{ "type":"string" }, "dateAvailable":{ "type":"string" }, "doi":{ "type":"string" } } } }
--
You received this message because you are subscribed to the Google Groups "DSpace REST" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-rest...@googlegroups.com.
Visit this group at http://groups.google.com/group/dspace-rest?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Hi Bill,
Very neat stuff here. I'm glad to see it. The swagger page looks useful.
Here's some random notes I have from looking at your project.
I'm not sure how swagger gets generated, but from reading: https://github.com/wordnik/swagger-core/wiki/java-jax-rs
It looks like you add swagger to your pom.xml, add some configurations, it scans your resources in your API, and it generates this pretty UI for listing your resources, their properties/methods, and documentation?
I like the _metadata portion of the response.
"_metadata": {
"offset": 0,
"limit": 10,
"totalCount": 1
}I'm still wrapping my head around what HATEOAS means, and if its a buzz-word, or if it should actually be implemented.
If we're talking being Intent-Driven, then I'm guessing thats the distillation of the use cases.
Collection.properties.owningCollection is type Boolean, I don't know what that means.
Do we want to expose a route to follow the hierarchy/relationships between objects?
I guess we don't want to get stuck with DSpace's logic, but Collection has owningCommunity, and recursively upwards, it can have many predecessor Communities. Would we want to expose Community ID's or CommunityObjects.
Bitstream has been renamed to File. Thats fine with me. Would we want to have an endpoint for /bitstreams? or to funnel that through /files?
We don't have "smart" Author objects within our DSpace. I wish we did something better. On campus we have "Research in View" (formerly OSU:PRO) in which academics list their publications, and we have an API for that data, so perhaps we could marry the two together, but for now authors are text in either dc.creator… or dc.contributor…
Works looks like the "Intended Use" of Item. It has a depositingAuthor String property. Would we want to stick with text such as depositingAuthorFormatted which displays the authors name in an expected format, and then to have depositingAuthor as an AuthorObject? Ohh, but then I notice that there is an authors array of AuthorObjects.
I'm not sure what versions are, but I'm guessing if you can support multiple versions of the same Work/Item, then you can provide some alternates.
I'm not sure what "school" is for a work (we don't use that metadata). Is school an attribute of an author, is it the University where this work was created, is it an academic department within the university. After trying out a request with swagger, one value says school="Anthropology", so that must be the Academic Department / Subject.
package edu.harvard.dash.jersey.resources;