Versions Compared

Old Version 25

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 26

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: adding in suggestions from Bojan posted to dspace-devel

...

  • Revisiting REST API Discussion
    • Seems to be an assumption that we should only have one REST API
    • No reason why we cannot have multiple APIs, or even different implementations (and let the best one win out in the end)
    • Revisiting whether one REST API should 'wrap' all calls (several question this). Tim noticed Twitter (and many other sites) have many many REST APIs )
      • 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.
      • Comments from Bojan Suzic (via dspace-devel):

        I think this is a good idea. In some cases Twitter has multiple APIs for the reason of different underlying architecture and techical implementations. The other reason could be an iterative evolution of their services and infrastructure.
        In the case of DSpace - maybe this point could be considered from the functional point of view. Generally, all the REST API versions would depend on the same DSpace-API, so the rationale for separation could be based on some other asumption. For instance, user-centric (browse), admin-centric (update) or similar, and/or based on the development effort or resources necessary to carry out the change. The example for the latter may be an outstanding decision about future development which may hold development/release of the component or part which is already clear and non-disputable.

  • Business Logic API
    • Can we "mature" design/modeling of the Business Logic API by thinking of it more as a REST API?
    • Services that would be part of a Business Logic API:
      • Item Submission processes (special ingest workflow)
      • Reviewer Workflow processes
      • Creation processes for Collections / Communities (also includes initializing roles, template items, etc. – almost like a "workflow" process to create these objects)
      • Creation processes for Groups / EPeople?
      • Running Curation Tasks
        • Richard Rodgers notes he's already building a demo REST API for Curation Framework using Jersey (http://jersey.java.net/). This will be posted to GitHub in near future
      • Smaller Activities: User feedback, Statistics, metadata registry, bitstream format registry
      • Authority Control? (managing internal or external controlled vocabularies & taxonomies)
    • Questions / Concerns on Business Logic API
      • Need to avoid it being too "large" / all-encompassing.
      • Where do we draw the line between underlying "DSpace Business Logic" and UI? E.g. Is Search/Browse part of Business Logic API? Or is it a separate API?
        • Mentioned that DSpace Discovery Module has been made more generic (no longer Solr specific) – may be the basis for a separate "Search API"?
      • Can we simplify? Is the "Business Logic API" just the REST API (GET/POST/PUT/DELETE objects)? Or is it still more than that?
  • REST API usage of Sakai bus
    • Are we satisfied with the Sakai-based REST implementation? Sounds like several have concerns about complexity & ongoing maintanence
    • May need to work towards a new implementation – based on Spring WebMVC or something else (Jersey? Apache CXF?)
    • Should be able to still reuse much of existing REST API work – especially the modeling of DSpace Objects as Resources bound to URLs
  • Mobile Device Support - DSpace is lagging behind. How do we plan to move in this direction?
    • Several seem interested in this, but no one known to be working directly on it.
    • Two levels of mobile support: (1) Making current UIs more 'mobile friendly' , (2) making DSpace more RESTful to support building native apps/clients
    • Suggestion from Bojan Suzic (via dspace-devel):

      One approach in this direction could be based on ClientUI idea (from GSoC 2011). Atomization and usage of lightweight components/architecture could lead to easier and less resource intensive development, maintenance and customization of UI. Also usage of cross-platform tools such as jQueryMobile, phoneGap or similar (+ REST API) could provide better coverage and require a less effort.

We took notes & shared additional links via IRC. http://irclogs.duraspace.org/index.php?date=2012-02-28