Hi Helix, > 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.
Yes, pressed the wrong reply button :-( Ben is certainly on the dspace-devel list, so I took him out. > 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). Yes, I missunderstood that bit. Somehow your high level requirements not even contain 'it must do something' ;-) > These are great observations, Anja. The perfect place for them would > be the REST API review page [1], so please put them there. Will do. > 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. For our use case the user might be redirected from the http://hdl.handle.net/ and should end up in our Rubi based web site viewing the item. Wherefore we would need at least a method which translates between handles and database ids. Actually our REST takes both db ids and handles - if it has two parts it is an handle otherwise db id. >> * 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. We are on 1.8, so I used the 1.8.1 branch and it certainly want's username password for everything. But I seem to have done something wrong, even with correct credentials I always get 403. I assume the communication with the DSpace core did not work. (https://jspace.atlassian.net/wiki/display/DSPACEAPI/API+Documentation) stats too that they use authentication/authorization. >> * 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? They both do. I just tried on our staging server :-( java.lang.OutOfMemoryError: Java heap space java.util.Arrays.copyOfRange(Arrays.java:3221) Both APIs need more testing than I have done i.e. (wijiti) http://.../rest/communities.xml?user=x...@xxx.de&pass=yyy works, but http://../rest/communities/12.xml?user=x...@xxx.de&pass=yyy returns a 403 Bad username or password which is the wrong error message and documenation suggests that this ought to have worked. > 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. True. To be honest, we have not done very much yet and I probably least of all. I think we agreed that we don't like the Sakai entitybus and that there are better technologies out now and we talked about a 'user' centred API rather than a 'DSpace' centred API without any conclusions as yet. Sometimes it feels a bit awkward to start a conversation. Best regards, Anja ------------------------------------------------------------------------------ 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
