Page History

...

• Interaction/Code Share via GitHub.
  • Can we come up with some best practices for forking GitHub, so that we can all start to share code more easily? I.e. allow institutions to pull in code from one another, etc.
  • We may need to spend some time developing some GitHub best practices.
  • We should also leverage Maven to obviously create separate GitHub projects for features that can just extend DSpace API, etc.
• Business Logic API discussion led into talking about REST API as a potential area for this "common business logic"
• REST API - Who is using it? What should it do, and how should it interact with SWORD / Solr / etc.
  • No one in attendance is using REST API in Production .(though a few have used it for development)
  • We should try and "show it off" more by writing some simple Javascript "embed" code to embed DSpace Content in a website. We can post that code up to http://demo.dspace.org and enable the REST API there. This could also allow for more testing.
  • REST API should never create its own 'conventions' for common tasks. Rather it should use existing standards (e.g. SWORD for deposit, etc)
  • Question: Should REST API "wrap" things like SWORD & Solr (which can be accessed RESTFully themselves)? Could "RESTFul" DSpace just be a combination of SWORD + Solr + Admin REST API + other RESTFul interfaces?
    • Several in disagreement here. Pros/Cons to various approaches
    • Fedora actually has a separate REST API from Browse/Search. You Browse/Search via RSearch, and then lookup an item by ID via REST API. This approach allows you to simplify the REST API to very specific tasks, and use other existing services/interfaces where they are more 'standard' or widely accepted.
    • However, AuthZ is simplified if you 'wrap' everything (even with a thin wrapper).
    • Also if you 'wrap' the Search/Browse in REST API, then at a later time you could swap out Solr (or whatever) for something like Elastic Search, and your clients would not need to change.

...