REST API Positioning (SWORD2 vs CRUD REST)

[da...@symplectic.co.uk]

My name is Dave Budenberg, and I work at Symplectic, who produce the Elements Research Information Management System. 

We are currently planning to extend the integration between Elements and DSpace, both providing data for a DSpace repository and reading data from it. DSpace currently provides both a SWORD2 REST API and a CRUD REST API. Although these don't overlap completely in their functionality, it is not clear why two separate REST APIs exist. Key questions are:

1. What is the rationale/positioning of each these? 
2. What are the future development plans for them? 
3. What level of use and stability does each have?
   

Dave

[Tim Donohue]

Hi Dave,

Simply put, SWORDv2 and the DSpace REST API serve different use cases. As you noted already, there is some overlap between these use cases, but they also are different in many ways.

* SWORDv2 is an implementation of the (generic) SWORDv2 protocol: http://swordapp.org/sword-v2/sword-v2-specifications/  This protocol is not repository specific, and therefore could be used across several types of repositories (i.e. not just DSpace) assuming they all support the protocol.  Primarily, this protocol is used for depositing content (items) into repositories, and providing updates/changes to previously deposited content. It does not allow for a way to manage other types of objects (e.g. Collections, Communities, People, etc.)

* The REST API is DSpace specific. Its goal is to provide a way to interact with DSpace via non-Java languages or remote systems.  While SWORDv2 concentrates solely on depositing Items into a repository, the DSpace REST API provides ways to also manipulate/manage other types of content (e.g. Collections, Communities) as well as providing ways to browse existing content (Communities, Collections, Items). Literally, the goal of the REST API will be to "mirror" as much of the underlying Java API as possible to provide access to all of the capabilities of DSpace (it's not quite there yet though).  https://wiki.duraspace.org/display/DSDOC5x/REST+API

There are no plans to replace either of these APIs.  DSpace wants to remain compatible with the SWORD protocol (both v1 and v2) as other external systems rely on that compatibility.  At the same time, we do see a need for our own unique REST API, as it provides developers a way to interact with all of DSpace in a non-Java fashion.  Both APIs are maintained and considered stable. The REST API is newer, but has been receiving frequent bug fixes/enhancements in recent releases (and more on the way).

As for levels of use, at this time, we don't have any accurate way to track how many institutions are using each API.  But, we do have developers actively maintaining each and helping to fix bugs when they do arise (and making enhancements to the capabilities of the REST API).  If it is of any interest, we'd also encourage Symplectic to feel free to contribute back to enhancing these APIs as needed. Here's a link to our general Code Contribution Guidelines, if they are of interest: https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines

All in all, which API you utilize may depend entirely on your use cases. If you are primarily concerned with depositing/updating Items in DSpace (and other repository systems), then SWORDv2 would be a good choice.  If, however, your needs are beyond simple deposit/update, then you'll find additional features/options in the REST API.

Thanks,

Tim

-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

--
You received this message because you are subscribed to the Google Groups "DSpace Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-communi...@googlegroups.com.
To post to this group, send email to dspace-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/dspace-community.
For more options, visit https://groups.google.com/d/optout.

[Peter Dietz]

Hi Dave,

Thanks for reaching out to DSpace. Having good integrations probably benefits both Symplectic and DSpace.

1 - What is the rationale/positioning of each these? 

SWORD and SWORD2 came first, they implement the protocol. Primary usage is from people pushing content into the repository from their CRIS.

REST API (Jersey) was added in the past 2 years, with goals of being something you could perhaps build a new user interface on top of, build lightweight widgets, or to power system integrations. Personally, I wanted a break from the SWORD protocol, and wanted a lightweight, easy to learn web service. Posting to an endpoint with json data makes more sense to me, then having to create a zip, with a manifest, in mets.

2 - What are the future development plans for them? 

DSpace REST API (Jersey) is being positioned to powering a lot of future development for DSpace. We're currently piloting new user interfaces that run on top of the REST API, and people are building reporting tools on top of REST as well. So, REST is actively used, actively supported, and the roadmap is to implement more features, versioning, search, etc. We've received / merged several REST related pull requests this week.

I would like to see more integrations with DSpace REST API.

SWORD / SWORDv2 only really sees attention when there is grant funding to push it forward. Not actively being developed, but bugs can get resolved through the development process.

3 - What level of use and stability does each have?

SWORD / SWORDv2 gets used in production by several/many sites across the globe. Very stable, and not much activity.

DSpace REST API is the relative new comer. I don't have any metrics or reports from this, other than seeing people pushing projects to Github of works-in-progress, UI prototypes, language specific SDKs. 

________________
Peter Dietz
Longsight
www.longsight.com
pe...@longsight.com
p: 740-599-5005 x809

[da...@symplectic.co.uk]

Hi Tim & Peter,

Many thanks for your helpful and informative replies. Great to be able to understand your positioning and have confidence about future directions. 

Good integrations are beneficial for our customers, and our own organisations.

Dave