Page History

...

There was no central ProviderRegistry that you have to declare your path. Your free to use @annotations to get your code to respond to requests, and there are helpful parameter helpers to extract parameters into Java variables.

Some analyses between wijiti and hedtek APIs

• 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 (Jorum) changed that locally so that we can have either db ids or handles

• 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 But username passwords are transmitted in the header or as part of the request. What about anonymous use of the GET parts?

• 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)

• wijiti seems to return wrong error messages and (or) does not work as the documentation suggests:

  • http://.../rest/communities.xml?user=xxx@xxx.de&pass=yyy
    works, but

  • http://../rest/communities/2.xml?user=xxx@xxx.de&pass=yyy
    returns a 403 Bad username or password -- username password same as on first request and community with id 2 exists

• wijiti itself states that "PLEASE NOTE: This DSpace REST API implementation and its associated documentation is a work-in-progress. Some documentation is still missing and some REST API endpoints are either not completed or have not been implemented. It is recommended you do not use this API in production environments unless fully tested."