JERSEY-based DSpace REST API

133 views
Skip to first unread message

Peter Dietz

unread,
May 21, 2013, 5:38:22 PM5/21/13
to dspac...@googlegroups.com
Hi All,

I've bitten the bullet, and have figured out how to make a new tomcat webapp, and made it speak Jersey, and made it connect to the DSpace datasource. I wouldn't say it was easy.


I'm tremendously confused with DSpace Services, how to register, get a hold of a context, but I've slavishly copied from the DSpace-WebMVC project some of the web.xml and applicationContext.xml portions, and I'm able to wire this against my local install of DSpace.





http://localhost:8080/dspace-rest/collections




The code isn't complex yet, so maybe I'll continue pursuing this direction.

@Path("/collections")
public class CollectionsResource {

    /*
    The "GET" annotation indicates this method will respond to HTTP Get requests.
    The "Produces" annotation indicates the MIME response the method will return.
     */
    @GET
    @Produces(MediaType.TEXT_HTML)
    public String list() {
        StringBuilder everything = new StringBuilder();
        try {
            Context context = new Context();

            Collection[] collections = Collection.findAll(context);
            for(Collection collection : collections) {
                everything.append(collection.getName() + "<br/>\n");
            }

        } catch (SQLException e) {
            return "ERROR: " + e.getMessage();
        }

        return "<html><title>Hello!</title><body>Collections<br/>" + everything.toString() + ".</body></html> ";
    }






Peter Dietz

unread,
May 22, 2013, 3:08:18 PM5/22/13
to dspac...@googlegroups.com
I've been plugging away at getting some of my ideas into the API.

JSON/XML
I've made it produce JSON or XML representations, when thats in your headers (Accept: application/json, or Accept: application/xml). From your web-browser, you'll get HTML instead.



Some things I like about API's are to not expose your POJO-attributes directly, so I've built an "interface" class for Collection. Not a "Java Interface", but another class to be a facade/proxy/PoEAA-buzzword so that I'm not exposing org.dspace.content.Collection directly. Perhaps some of this "smelly" code can get moved to a business layer. For instance, I made Collection have an Integer logoID, instead of Bitstream logo. Also, then instead of it being a field ID, its now collectionID.

Another piece of funny-business that I added is ?expand. This coming from Atlassian's expansion guidelines. So, for expensive operations that you don't always want to pay the price for, you can tack the ?expand= Query Parameter to the end of the query string. Thus far, I have it taking itemIDList, parentCommunityID, parentCommunityIDList. All-together now: http://localhost:8080/dspace-rest/collections/?expand=parentCommunityID,parentCommunityIDList,itemIDList


Getting a collection/{collectionID}, has a cost of roughly 1. (Fetching each piece of metadata is distinct queries though). ~= 1
Getting a collection/{collectionID}?expand=parentCommunityID,parentCommunityIDList,itemIDList is multiplied by N parent communities, then M child items. ~= 1*N*M


One of the next things I want to think about are setting a scope. i.e. /communities/{communityID}/collections, and the collection list will be the subset contained within the parent community.

Then, setting query limits. i.e. default query nets you 50 results, as opposed to 1000+, depending on how much is in your system.

Feel free to join the discussion, I'm really just building away without a set plan, until I end up with something useful.
Reply all
Reply to author
Forward
0 new messages