no problem. see you Tuesday. Ed
Sent from my iPhone > On Oct 15, 2014, at 10:45 AM, "dspace-devel-requ...@lists.sourceforge.net" > <dspace-devel-requ...@lists.sourceforge.net> wrote: > > Send Dspace-devel mailing list submissions to > dspace-devel@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/dspace-devel > or, via email, send a message with subject or body 'help' to > dspace-devel-requ...@lists.sourceforge.net > > You can reach the person managing the list at > dspace-devel-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Dspace-devel digest..." > > > Today's Topics: > > 1. Versioning the REST API, i.e. /rest/v1, /rest/v2 (Peter Dietz) > 2. Re: Versioning the REST API, i.e. /rest/v1, /rest/v2 (helix84) > 3. Re: Versioning the REST API, i.e. /rest/v1, /rest/v2 (Peter Dietz) > 4. Re: Versioning the REST API, i.e. /rest/v1, /rest/v2 (helix84) > 5. DSpace Dev Mtg Tomorrow @ 20:00 UTC and JIRA Backlog Hour @ > 19:00 UTC (Tim Donohue) > 6. Pascal's Linked Open Data PR (Peter Dietz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 13 Oct 2014 11:19:54 -0400 > From: Peter Dietz <pe...@longsight.com> > Subject: [Dspace-devel] Versioning the REST API, i.e. /rest/v1, > /rest/v2 > To: dspace-devel@lists.sourceforge.net > Message-ID: > <cacl+z9uk_xstgzncjbd22eqvrwup2aeckudku2ny8z-o5gi...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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: > https://www.youtube.com/watch?v=Ba9TL1Pl5pw > > This CRUD API is very similar to the existing read-only API, the structure > of most responses is very similar. But, there are some minor tweaks. So, > I'm wondering what the advice of the crowd is? Should we just have DSpace 5 > ship with a changed API? Or should we bother with "versioning" the API? > > i.e. DSpace 4 Read-Only API to be available at: /rest/v1 > and DSpace 5 CRUD API to be available at: /rest/v2 > ? > > Thoughts... > > I'm not sure how widely used the existing READ-only DSpace 4 API gets. i.e. > If you didn't use DSpace 4 rest, then there's nothing to worry about. But, > if you have built some integrations / apps on the DSpace 4 API, there will > be the minor changes... So, what's to best way to inform API consumers that > when you upgrade these are the changes that you need to make to your > consumer app immediately. Or, do we go the extra mile now to add api > versioning (which unfortunately would need to be > yet-another-thing-to-spend-development-time-on, and > yet-another-thing-to-support). > > > > ________________ > Peter Dietz > Longsight > www.longsight.com > pe...@longsight.com > p: 740-599-5005 x809 > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 2 > Date: Mon, 13 Oct 2014 18:11:30 +0200 > From: helix84 <heli...@centrum.sk> > Subject: Re: [Dspace-devel] Versioning the REST API, i.e. /rest/v1, > /rest/v2 > To: Peter Dietz <pe...@longsight.com> > Cc: DSpace Developers <dspace-devel@lists.sourceforge.net> > Message-ID: > <cagdvkqi+p8tak0gbrxyygx1z+g3iy3zgs4vk92-um++5ygd...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > 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 versions in DSpace 5. Which would be > great, but is this what you're going to do? OTOH, if you're only > informing the user of API version, just make it part of the response > (e.g. <api-version>5</api-version>) to an info endpoint (a.k.a. > Identify in OAI-PMG or servicedocument in Atom). > > Regards, > ~~helix84 > > > > ------------------------------ > > Message: 3 > Date: Mon, 13 Oct 2014 12:23:29 -0400 > From: Peter Dietz <pe...@longsight.com> > Subject: Re: [Dspace-devel] Versioning the REST API, i.e. /rest/v1, > /rest/v2 > To: heli...@centrum.sk > Cc: DSpace Developers <dspace-devel@lists.sourceforge.net> > Message-ID: > <CACL+z9X84ORRmQMHXBtRx1LypTz6mgk5j5yD6o+Ym-=rst9...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 endpoint to get the data: /communities/:id/collections > > I'm thinking the same /rest webapp could include both v1 and v2 routes, > just put them into another package, and annotate the routes. It's just this > is extra effort, it adds to the maintenance burden, it causes the api to be > less simple, and I'm just planning to deprecate/remove the v1 stuff, and > make v2 the new default. So, just a crutch so that you don't break your > rest consumer apps. Which is why I'm wondering if this is even necessary. > > ________________ > Peter Dietz > Longsight > www.longsight.com > pe...@longsight.com > p: 740-599-5005 x809 > >> On Mon, Oct 13, 2014 at 12:11 PM, helix84 <heli...@centrum.sk> wrote: >> >> 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 versions in DSpace 5. Which would be >> great, but is this what you're going to do? OTOH, if you're only >> informing the user of API version, just make it part of the response >> (e.g. <api-version>5</api-version>) to an info endpoint (a.k.a. >> Identify in OAI-PMG or servicedocument in Atom). >> >> Regards, >> ~~helix84 >> > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 4 > Date: Mon, 13 Oct 2014 18:31:32 +0200 > From: helix84 <heli...@centrum.sk> > Subject: Re: [Dspace-devel] Versioning the REST API, i.e. /rest/v1, > /rest/v2 > To: Peter Dietz <pe...@longsight.com> > Cc: DSpace Developers <dspace-devel@lists.sourceforge.net> > Message-ID: > <CAGdvKqgLN=spy_rds1d3ovuvudypesf4vtwxjvmycxy9y+t...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > 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 needed for > future changes anyway (so it should have been part of DSpace 4 REST, > but it's no use of crying over spilled milk now) > > > Regards, > ~~helix84 > > > > ------------------------------ > > Message: 5 > Date: Tue, 14 Oct 2014 17:23:56 -0500 > From: Tim Donohue <tdono...@duraspace.org> > Subject: [Dspace-devel] DSpace Dev Mtg Tomorrow @ 20:00 UTC and JIRA > Backlog Hour @ 19:00 UTC > To: dspace-devel <dspace-devel@lists.sourceforge.net> > Message-ID: <543da27c.4020...@duraspace.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > All, > > Tomorrow (Weds, Oct 15) at 20:00 UTC, we have our weekly DSpace > Developers Meeting in the #duraspace IRC channel. To determine your > local time, check the world clock: > http://www.timeanddate.com/worldclock/fixedtime.html?hour=20&min=0&sec=0&p1=0 > > The agenda is posted on our Developer meetings page at: > https://wiki.duraspace.org/display/DSPACE/Developer+Meetings > > The notes from last week's meeting are also available off of the > "Meeting Archives" area of that page. > > As always, all our meetings are public. We welcome any developers or > non-developers to attend or just read along with the chat discussions. > > If you are unable to attend, you can always add your own notes/thoughts > on any agenda item to the above wiki page. > > == JIRA Backlog Hour == > > The hour prior to our Developers Meeting, we will be holding a "JIRA > Backlog Hour" in #dspace IRC (note that it takes place in #dspace and > NOT #duraspace). > > During this meeting, developers who are available will begin to work > together to tackle our backlog of "Received" tickets/bug reports in > JIRA. We'll be looking to do a quick analysis of tickets to help move > them along through our workflow. Anyone is welcome to join us (and you > are more than welcome to just join mid-meeting as well). > > It's a great way to learn about how we work together to support DSpace, > and also a great way to contribute to DSpace software. Plus, you'll be > helping all of us to determine which tickets (old and new) could use > extra love & attention. > > Our current JIRA "Received" backlog is at: > https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+status+%3D+Received+ORDER+BY+key+ASC%2C+priority+DESC > > We hope to see you in IRC! > > Thanks, > > Tim Donohue > Technical Lead for DSpace Project > DuraSpace.org > > > > ------------------------------ > > Message: 6 > Date: Wed, 15 Oct 2014 11:44:31 -0400 > From: Peter Dietz <pe...@longsight.com> > Subject: [Dspace-devel] Pascal's Linked Open Data PR > To: DSpace Developers <dspace-devel@lists.sourceforge.net>, > dspace-rele...@lists.sourceforge.net > Message-ID: > <CACL+z9XNmZqGt4ogfDrSGFf=3t5cvlojqqunpoalxfbhs3n...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi All, > > Not sure if I should email dspace-devel or dspace-release. Cross posting... > > FYI, I'm +1 on Pascal's Linked Open Data PR. > https://github.com/DSpace/DSpace/pull/568 > > I'm hoping people can review that, and/or comment with their opinions. So > we can press or not press merge. One of the hopes is that a follow-up PR > will happen to this ticket, which adds the dspace-oceanlink/dspace idea of > the sesame triple store, so this can work out of the box. The current PR > requires some setup, such as adding Apache Fuseki. > > ________________ > Peter Dietz > Longsight > www.longsight.com > pe...@longsight.com > p: 740-599-5005 x809 > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > > ------------------------------ > > _______________________________________________ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > > End of Dspace-devel Digest, Vol 101, Issue 3 > ******************************************** ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
