Hi Anja, I see you didn't include the Wijiti and Jorum guys in CC, I'm adding them again to keep them in loop because I'm not sure if they're on dspace-devel.
On Fri, Sep 20, 2013 at 1:06 PM, Anja Le Blanc <anja.lebl...@manchester.ac.uk> wrote: > I see the advantage of getting something official out rather than nothing. > But I can also see the millstone of than having to remain compatible with > what was once released. I completely see your point. However, the discussion is moot if we don't have any candidates meeting even the minimal criteria. The out-of-tree candidates have been available for several DSpace releases now, so we can say already tried letting people play with them, comment on them, improve on them in order to determine what would be the perfect API. The result is we still have nothing in DSpace. That's why the latest commiter consensus seems to be that it's better to have something non-perfect but in-tree that can be improved rather than nothing. > I assume the DSpace commiters are generally happy with the set of end points > the two API expose at the moment.(?) (That was one of the starting > discussions we had about developing a third API.) You mentioned that you > formulated a minimal set of requirements. Could you sent me a link to that? Sorry, I probably wasn't completely clear. The commiters agreed on high-level requirements the API should have (listed in my first email in this thread) so that we can consider it for merging. We didn't discuss the "syntax" of the API (endpoints, parameters, formats). Personally, I don't think it's reasonable to expect any such changes on the short time remaining before the deadline, that's why we didn't go into details. > The question of which current API is better, is somewhat difficult. These are great observations, Anja. The perfect place for them would be the REST API review page [1], so please put them there. I'd put them there myself, I just have some questions for clarification: > * They both are based on the same underlying technology (Sakai entitybus) - > which in my opinion makes it pretty hard to do any developments with them. > * They both use database ids rather than handles -- we changed that locally I think database IDs are the right choice at this time. The general trend lately has been to abstract external identifiers (so that we can have DOI or NBN or whatever instead), therefore we don't want to be dependent on handles internally. I know the nuisance with database IDs is that there is a separate sequence for different objects. But the composite key (resource_id, resource_type_id) is unique within a DSpace instance. > * Hedtek does not have any kind of authentication, which would not be > suitable for places with restricted access. Wijiti seems to want a user name > password for everything (I am not completely positive of whether this is > true for a clean fresh checkout of the code.) But username passwords are > transmitted in the header or as part of the request. Could you please verify that in the original code? It seems we've been assuming Wijiti doesn't support authZ. > * For people who have to report on the usage of their repository, you have > to note that neither API submits usage stats to solr (or anywhere else) > * For the Hedtek API not all the endpoints are implemented which are > 'advertised' (i.e. search and I have only looked at the once we wanted to > use) > For a service environment I think Hedtek would be the safer choice (except > for possibly bringing down the service) as there is no way for it to modify > content of the repository. "bringing down service" - so it's in Hedtek's case that listing all items can crash Tomcat? Or did I misunderstand? Great review, the more information you can give us, the better commiters will be able to decide. By the way, one of the guys behind the two implementations said you (as in the REST API "working group") never contacted them with any comments whatsoever. As they're heavily invested in using REST API, they would surely like to hear any problems you encountered with their implementations and that, in turn, helps everyone. Thank you for all your work on REST API so far. [1] https://wiki.duraspace.org/display/DSPACE/Review+of+Existing+Dspace+REST+API+Frameworks Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
