Hi Michael,
Thanks for this!
Our plan has been to mention this Wijiti version, and encourage people to
begin or continue trying it. I know of several groups that are already
using a combination of this and/or the Hedtek version to power their
production DSpace instances or portions of their site.
Hi All again
Hot on the heels of the 3.x merge of the REST API into DSpace, we have
released a 1.8.x version as well.
http://bitly.com/Q12Xgp
Hope this helps the discussion today
Cheers
Michael
On 11 July 2013 06:41, Michael Guthrie wrote:
> Hi All
> We couldn't be there for the OR2013 con
Hi Jonathan
If useful for you:
https://github.com/wijiti/dspace-rest-api
documentation at:
https://jspace.atlassian.net/wiki/display/DSPACEAPI/DSpace+REST+API+Home
It is a complete rework of the GSOC version of the REST API; we have
also added some new endpoints, reworked others and added mo
Hi
Alas, our involvement was always strictly limited in that we doing work for
a client who used DSpace. So seems unlikely that we will ever working with
Wijiti on this (good suggestion though).
But we are interested in seeing our work becoming part of something larger
in the DSpace world, so we
There's also the Wijiti fork:
https://github.com/wijiti/dspace-rest-api
That one was seemingly more active recently. Mark, are you in touch
with them? Why not work together?
Regards,
~~helix84
Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+L
Hi Jonathan and Hardy
Our (Hedtek's) version is basically a fast read-side only version of
Bojan's summer of code RESTful API.
We were luck enough to have a senior member of the ASF working for us for a
while, and he did wonders with test-first refactoring Bojan's code and
hooking it up (as I rec
Hi, Jonathan, you may want to check out the Hedtek version of the REST-API:
https://github.com/hedtek/dspace-rest
This isn't any sort of formal answer to your question, but, I'm planning
to do a bit of tinkering with DSpace and REST myself, and I intend to use
the Hedtek version for that tinkerin
Hi Tim,
I think a good point was made on the Virtual Summit meeting notes, namely "No
reason why we cannot have multiple APIs, or even different implementations (and
let the best one win out in the end)".
As part of a previous project, we took that approach and created our own DSpace
API based
Hi all,
I will comment a few points as I am not able to attend the summit.
---
https://dev.twitter.com/docs - Twitter specifically has a basic REST
API, Search API, Streaming API, etc. They even do OAuth / AuthZ via REST
API.
---
I think this is a good idea. In some cases Twitter has multiple
Hi All,
Just wanted to follow up on this thread from a while back about the
question of using the "Sakai bus for the REST API". I think Bojan gave
a great description of why this decision was made initially.
However, it's worth mentioning that this topic came up in today's
discussion at our "
Hi Mark,
Am 07.02.2012 17:36, schrieb Mark van Harmelen:
> * Many exceptions are being caught and thrown away. We predict that in
> times of trouble this will make the API impossible to debug.
Many of the exceptions are related to handling of access rights of
request sender and some other
All,
I've just added a new "Component" to the DSpace 1.x JIRA section for
"REST API (experimental)".
http://jira.dspace.org/jira/browse/DS/component/10061
Please try to report any bugs or issues that you find with the REST API
under that component. So, just report it as you would any other
b
12 matches
Mail list logo
