Skip to main content

Notice

We are in the process of rolling out a soft launch of the RDA website, which includes a new member platform. Existing RDA members PLEASE REACTIVATE YOUR ACCOUNT using this link: https://rda-login.wicketcloud.com/users/confirmation. Visitors may encounter functionality issues with group pages, navigation, missing content, broken links, etc. As you explore the new site, please provide your feedback using the UserSnap tool on the bottom right corner of each page. Thank you for your understanding and support as we work through all issues as quickly as possible. Stay updated about upcoming features and functionalities: https://www.rd-alliance.org/rda-web-platform-upcoming-features-and-functionalities/

Meeting Notes: 10 May Webconference

  • Creator
    Discussion
  • #83140

    Hi all,
    Here are my notes from Tuesday’s discussion. Please correct/augment as necessary.
    We discussed and decided on a number of issues stemming from Frederik’s first round of feedback on the API (https://github.com/RDACollectionsWG/apidocs/issues/1)
    PID Assignment: an implementation of the API should:

    include a default provider for assigning PIDs which implements the PIT API
    allow for a client to supply an endpoint for an alternate PIT API provider as a parameter to the CREATE request for a Collection
    declare in a capabilities call to clients what the default provider is and what providers can or cannot be used (i.e. a whitelist/blacklist)

    Capabilities

    current operations to get the list of supported access types and model types should be assumed under aforementioned capabilities operation
    additional capabilities to declare include the max limit on # of collection items which can be operated on in a single request (i.e. CREATE, UPDATE, DELETE)

    Cursors: 

    POSTs of new Collections should return a single item, not a Cursor
    Requests which return a set should return a cursor

    Transactional and error handling questions on adding multiple items at once to a collection

    we will restrict scope to support only synchronous requests
    POSTS which operate on multiple items where not all succeeded should return a FAILED status and provide some way for the client to know which failed and which succeede

    Responsibility for dealing with recursiveness (collections of collections) is pushed to the client ? [ my notes on this point are fuzzy ]
    Other items: Tobias will apply for a session at P8
    Please chime in with whatever I missed.
    Thanks!
    Bridget
     

Log in to reply.