Hi Helix, 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 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? The question of which current API is better, is somewhat difficult. * 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 * 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. * 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. Best regards, Anja On 19/09/2013 14:57, helix84 wrote: > On Thu, Sep 19, 2013 at 3:23 PM, Anja Le Blanc > <[email protected]> wrote: >> What are the consequences for future developments of one of these API's >> getting into 'core' DSpace now? > > Hi Anja, > > as you know, people have a lot of use cases that could be addressed by > a REST API and the need for it has only grown in time. Therefore the > commiters group wants to give users _something_ official to play with > that can be supported and developed. With the 4.0 release imminent and > no official pull requests filed, we've reconsidered all the > alternatives. We agree that: > * it's beneficial for the DSpace community if we commit to an official API > * we would like to to include something usable even if it's not > feature-complete > * even if the underlying implementation would change or even be > completely rewritten > * because of the possibility of change, we're considering having the > API versioned > In addition to that, we finally formulated a set of minimal > requirements for making an API official (we probably should have done > that much sooner, sorry!). > > So, to answer your question, the consequence would be a wider exposure > of the chosen API to DSpace users (thanks to lowering the barrier of > entry and the official status). Hopefully, getting more users will > result in discovering its deficiencies and getting improvements. > >> If a new API would come along - in a year or so - does it need to be >> compatible with the one getting into DSpace now? Or should all >> developments in future be done one the one API? > > Ideally, the chosen API would change as little as possible. However, > the underlying implementation can change as needed at any time. > > Should it turn out that the API itself would benefit from changes, we > might release a new version available as a separate URL endpoint. This > is still open for discussion. > > In any case, the goal here is to give it a wide exposure and we're > expecting that will help identify weak points, so for 4.0, we'd slap > some sort of beta label on it. > >> We are using both Wijiti and Hedtek and are not completely happy with >> either. For once run a GET on all items on a repository with enough >> content and your Tomcat can easily run out of memory and die. Not very >> suitable for a service environment. > > You're one of the few users who worked with both and are able to judge > which one is better. What we currently care about the most is which > API is the best to work with, not which implementation. If the problem > you mentioned is inherent to the API design, the API design should > change (e.g. adopt resumption tokens like in OAI-PMH). > > Even if you think that all the available APIs are way too cumbersome > to use and we'd be better off waiting for another year for a design > from scratch, we'd still like to hear your opinion. > > > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
