Hi All,
I have submitted a Pull Request for the JERSEY based implementation I have
been working on: https://github.com/DSpace/DSpace/pull/323
I would appreciate review, feedback, and ways to incorporate more features
and improvements into it.
Peter Dietz
On Fri, Sep 20, 2013 at 11:10 AM, Anja Le Blanc <
anja.lebl...@manchester.ac.uk> wrote:
> 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
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
