Page History

...

• 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. 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.
• 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/^{Image Modified}). 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
    • http://en.wikipedia.org/wiki/Responsive_Web_Design

...