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.leblanc@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.
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

Both APIs need more testing than I have done
i.e. (wijiti)
works, but
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,

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.
Dspace-devel mailing list