[Dspace-devel] Versioning the REST API, i.e. /rest/v1, /rest/v2

2014-10-13 Thread Peter Dietz
Hi All, The Jersey REST API that shipped with DSpace 4, lets call the DSpace REST API v1. (Yes, there were other API's before it, Hedtek, Wijiti, GSOC). In DSpace 5, the REST API is still based on JERSEY, and it will add CRUD operations. See demo of DSpace 5 CRUD REST API:

Re: [Dspace-devel] Versioning the REST API, i.e. /rest/v1, /rest/v2

2014-10-13 Thread helix84
Hi Peter, On Mon, Oct 13, 2014 at 5:19 PM, Peter Dietz pe...@longsight.com wrote: i.e. DSpace 4 Read-Only API to be available at: /rest/v1 and DSpace 5 CRUD API to be available at: /rest/v2 this (ability to request a particular API version) makes sense only if you're going to expose both API

Re: [Dspace-devel] Versioning the REST API, i.e. /rest/v1, /rest/v2

2014-10-13 Thread Peter Dietz
I really just want to gracefully migration from v1 syntax to v2. (In reality it's more of v1 to v1.1, where one or two things cause some incompatibility), i.e. getting parent community list or something is named slightly differently, and/or to get subcollections you would need to call another

Re: [Dspace-devel] Versioning the REST API, i.e. /rest/v1, /rest/v2

2014-10-13 Thread helix84
It's great that it's relatively simple to make that change. I'm going to argue for versioning: 1) since we're talking about an API that was released (in DSpace 4), it's reasonable for users to expect that it won't change (unless versioned) 2) preparing the infrastructure for versioning will be