Tim Donohue [10:23 AM] Ok, now it's time for the DSpace 7 REST API updates @here. I'm going to hand this over to @bollini to lead the updates Andrea Bollini [10:24 AM] we have three updates for the past week Terry Brady [10:24 AM] Hello Andrea Bollini [10:24 AM] 1. a question has been posted on the REST7Contract https://github.com/DSpace/Rest7Contract/issues/8 [10:25] this is a good news because it means that people start to be aware of the repo and the ongoing work but also show that the goals of the new REST API are not well known by most of the community [10:26] I hope to start a conversation on that so that other can help to identify all the area that need to be supported in the new REST API
Terry Brady [10:27 AM] It would be useful to enumerate all of those features on the endpoints page. It will help us realize how much work there is to complete. Andrea Bollini [10:28 AM] yes, my suggestion is to open PR against the endpoint page as soon as we identify a new area / function that need to be supported
Tim Donohue [10:29 AM] I agree. In general, it'd be good to add brainstormed endpoints to the "Proposed Endpoints" section, even if we don't yet know what the full endpoint name/path should be yet [10:29] https://github.com/DSpace/Rest7Contract/blob/master/endpoints.md#proposed-endpoints Andrea Bollini [10:30 AM] 2. we have a PR merged (CORS support https://github.com/DSpace/DSpace/pull/1749 ) and a PR waiting for approval https://github.com/DSpace/DSpace/pull/1750
[10:31] I want to update the demo website of the api so if we agree about 1750 I will prefer to have that merged before the update Terry Brady [10:31 AM] Based on a very fast scan, I like the concept Tim Donohue [10:32 AM] I like that 1750 makes the "{apiCategory}" easy to update (especially since we may want to do this in other areas as we add more endpoints). +1 Andrea Bollini [10:33 AM] @terrywbrady I will add you as reviewer so that you can formally approve Terry Brady [10:33 AM] Sounds good. [10:33] Could you re-share the link to your demo site Andrea Bollini [10:33 AM] we already agree that the new api are under heavy development so don't take it too seriously :slightly_smiling_face: [10:34] http://dspace7.4science.it/dspace-spring-rest/ Terry Brady [10:34 AM] thanks Andrea Bollini [10:35 AM] last update from my side 3. I have updated the documentation about the code practice for the new REST API https://wiki.duraspace.org/display/DSPACE/DSpace+7+REST%3A+Coding+DSpace+Objects Mark Wood [10:35 AM] Please, when adding to Rest7Contract, make it very clear what is settled (for now) and what is brainstorming.
Pinned by you May 25th at 10:36 AM Pinned by you Tim Donohue [10:35 AM] The DSpace 7 REST API demo is at http://dspace7.4science.it/dspace-spring-rest/ (edited)
[10:36] :point_up: I just added that so we can pin it easier Andrea Bollini [10:36 AM] to clarify it uses the same backup data than demo.dspace.org but it is not linked to the same database Tim Donohue [10:37 AM] Thanks for the clarification. I'll just take that point off the pinned link then, @bollini :wink: Andrea Bollini [10:38 AM] I ask you to check the coding documentation page as I have tried to explain a bit the direction that I'm following to solve the most pressure issues that we have [10:38] essentially it should (hopeful) clarify a bit what I tried to explain in the last week hangout call Tim Donohue [10:39 AM] Thanks for those docs, @bollini! I'll give them a more thorough read today (I haven't had a chance to read them yet). I'd encourage others to do so as well! Terry Brady [10:39 AM] I will as well Mark Wood [10:39 AM] Ditto Andrea Bollini [10:40 AM] ok thanks [10:40] I haven't other update. As 1750 as been formally approved I'm going to merge and update the demo website at the end of this meeting Tim Donohue [10:41 AM] Sounds great, thanks! Terry Brady [10:41 AM] I have a couple of loosely related items [10:42] If any of you can travel to Wash DC in Aug, I want to make sure you are aware of this event: https://www.library.georgetown.edu/node/19724 library.georgetown.edu DSpace North American User Meeting | Georgetown University Library [10:42] We plan to have some DSpace 7 conversations. Tim Donohue [10:42 AM] And an Angular training session! :wink:
Terry Brady [10:43 AM] Also, in some of my recent DSpace 6 work, I have had a greater desire to run cloud instances of DSpace for rapid/easy testing.
[10:43] I took a look at codenvy.io which offers a cloud-based IDE+runtime. I am curious to know if anyone is doing somehting like this in their development workflows [10:44] I am finding it tricky to work in DSpace 5,6 and 7 on the same box Tim Donohue [10:45 AM] FWIW, I've mentioned this codenvy.io investigation within DuraSpace to the other teams (Fedora, DuraCloud, VIVO). No one else is aware of such work in other projects, but sounds like there's a general interest in hearing about our experiences (as we gain more)
Andrea Bollini [10:46 AM] I'm not using cloud-based IDE yet. It is something that I want to explore as well when.... I will have the time :disappointed: to work on different version of dspace up to now we use different eclipse workspace and installation directory Tim Donohue [10:46 AM] And for more context, the codenvy.io stuff uses Eclipse Che (cloud based IDE): https://eclipse.org/che/ eclipse.org Eclipse Che | Eclipse Next-Generation IDE, Cloud IDE, and Workspace Server Eclipse Che Next-Generation Eclipse IDE. Terry Brady [10:46 AM] If anyone starts exploring this, please let me know. It would be good to coordinate efforts. Mark Wood [10:47 AM] I just have a few scripts that write mostly-identical local.cfg and Tomcat contexts. The problem I usually have with multiple development streams is having to commit stuff to my local repository in a half-finished state when I need to switch.
Terry Brady [10:47 AM] I had hoped we could host Che on our dev server, but it will require several upgrades to meet the specs Tim Donohue [10:49 AM] I'm very interested in the Eclipse Che + Docker in codenvy.io investigations. I admit though, I'm not sure I'll have much time in the near future to contribute. But, it seems promising especially for helping us all support older versions of DSpace (in a shared cloud dev environment)...and also for workshops/training at conferences perhaps Andrea Bollini [10:50 AM] Sorry to come back to the new REST API. I want to say that there are still 3/4 big area where no work is yet started [10:51] 1. we should start to think / play in update operation (send a new json representation to update an item, etc.) [10:52] 2. we need to think about authentication (if I remember correctly @tom_desair says something on that when we started the work on dspace7, so he could be interested to join the conversation) Tim Donohue [10:53 AM] +1 to both Andrea Bollini [10:53 AM] 3. we need to explore the test / documentation framework ( https://jira.duraspace.org/browse/DS-3484 ) [10:54] 4. we need to start to think / play with the authorization issue [10:55] I will open issues for these points but I appreciate help on that Tim Donohue [10:55 AM] I was just going to suggest a JIRA ticket for each...and perhaps ping Tom by name on the Authentication piece. [10:56] Regarding AuthN / AuthZ, there obviously are opportunities for major overhauls in how we do this (in general). But, I do want to caution us to be careful to scope them both to something that is "reasonable" to implement in time for DSpace 7 [10:57] Longer term, it'd be good to move towards Spring Security. But, I'm not against simply going with something based on "what we have" for DSpace 7...and move towards Spring Security in DSpace 8 (edited)
Mark Wood [10:57 AM] We need to be vigilant, not to let any authNZ code leak over the wall into the UI. Tim Donohue [10:57 AM] +1000 :wink:
Andrea Bollini [10:59 AM] we have almost hit the hour, are there any questions on the rest work that you like to discuss? Tim Donohue [11:00 AM] No questions from me, but I do want to mention I think this is great progress. I'm also glad to see the wiki docs on code best practices (and am looking forward to the feedback from others on those) Terry Brady [11:00 AM] Since we are creating a new paradigm with a REST layer, what is the optimal authentication approach? Are our old mechanisms appropriate? [11:00] I do not need an answer now, that is just a question that comes to vincentminde Tim Donohue [11:02 AM] "Optimal" in the longer term is likely Spring Security: https://projects.spring.io/spring-security/ (as it aligns with all the other areas of the code, being that it's a well adopted framework out of Spring). But, personally, I'm not certain that's "achievable" in time for DSpace 7 (as it seems like a major overhaul). So, we may need to find an "in between" step to get us closer in that direction [11:02] That said, this likely requires analysis of options and reporting back to us for a final decision Mark Wood [11:03 AM] Do you mean forms of authentication, or how we authenticate? Andrea Bollini [11:04 AM] authorization is the big challange. I think that we can make change to the authentication more easily Tim Donohue [11:05 AM] If we are talking LDAP, Shibboleth, OAuth etc... I think we want to minimally maintain what we currently support in DSpace 5/6. Tim Donohue [11:05 AM] notes though that we are over time here. Not sure we need to answer this all directly now. But, these would be good points to bring up in a JIRA ticket about DSpace 7 REST API AuthN Andrea Bollini [11:07 AM] we have two issues here probably. One is how to validate the credentials (and what we have for dspace 5/6 is probably good enough for now) and one is how to share the authenticated credentials between REST call [11:08] the DSpace 5/6 REST uses session cookie for that (if I'm not wrong) that is not optimal for clustering and for developer of REST client Tim Donohue [11:09 AM] Unfortunately, I have to leave here shortly (for another meeting). I'd recommend we move this discussion to the future JIRA ticket. We'll keep this all in today's notes (once I copy this over to the wiki) as well. Mark Wood [11:09 AM] That depends on where you store the session. Terry Brady [11:09 AM] We never build a "real" application on top of the 5/6 REST api, so I would not assume that those mechanisms are reliable for a full application Tim Donohue [11:10 AM] It sounds like the next steps are to create the ticket, analyze how this was done in teh DSpace 5 and 6 REST APIs (as AuthN is slightly different between those two versions even), and determine options for DSpace 7 [11:11] So, with that, I'd recommend we close up today's meeting. Thanks all again for a productive week (and please give the REST coding best practices a read)! Next week we'll be on Google Hangouts.
Terry Brady [11:12 AM] Have a good week! Mark Wood [11:12 AM] 'bye for now.
Tim Donohue [11:12 AM] Thanks all! |