Page tree
Skip to end of metadata
Go to start of metadata


 from 15:00-16:00 UTC

Location: (Meeting ID: 502 527 3040).





(Notes below copied from last meeting. Details will be updated during this meeting.)

  • General Updates (Tim)
    • Tim thanks all for efforts on getting OR2019 presentations in.  Full list at DSpace 7 at OR2019
    • Notes discussion at Steering Group (yesterday) that we won't make current Preview Release goal (end of Jan).  Suggestion out Steering was to have a Planning meeting of core contributors (DuraSpace, Atmire, 4Science) to discuss how to update the schedule, and brainstorm ways to speed up development/review processes and better stay on schedule. 
      • Tim will send out a Doodle poll this week to hopefully schedule meeting sometime next week
  • Unblocking REST API PRs
    • Tim summarized discussion from last meeting & feedback from Andrea in #rest-api Slack channel.
    • Lots of back and for discussion & clarification occurred. This cannot be accurately documented, so I've summarized the decision / main points below.
    • Final decision on managing relationships/links via PUT/POST (this is a summary of several back & forth discussions, which finalized in these main points)
      • In general, we should be aiming to align with Spring Data REST best practices (where they exist)
      • In Spring Data REST, the best practice to create/update/manage associations (i.e. links) between resources (DSpace Objects) is to do the following:
        • First, create all resources (objects) the need to be linked (via appropriate POST requests), if they are not already created
        • Second, establish the relationship between resources by sending a PUT request to the main object's association endpoint, where the following is true
          • The request body of the request should be a list of URIs to link/associate with the main object
          • The request content type should be "text/uri-list".
        • Better examples of this recommendation exist here
      • Relationships on Object Creation (usually POST)
        • For object creation (POST of new object) in DSpace, we usually need to send the whole object representation (JSON) in the request body.  For DSpace REST API, we've chosen to always send JSON in the request body (Content Type: application/json or application/hal+json)
        • There are some object types in DSpace that cannot be created without a Parent Object (i.e. without a link/association to another object).  Such examples include Items (which cannot be created without a Collection) and Collections (which cannot be created without a Community)
          • In this scenario, we cannot align directly with Spring Data REST best practices as the POST request (to create the object) must also specify the link/association (with the Parent Object).  The alignment is impossible in this scenario because we cannot send a single POST request that sends both JSON (application/json) content and "text/uri-list".
          • Therefore, in this scenario, we have chosen to specify the link/association via a query parameter in the POST request. So, for example, a new Collection is created via a single POST request that passes the (new) Collection data in the request body (as JSON) and the Parent Community link as a parameter (e.g. ?parent=[uuid]).
        • For any object types that can be created without a Parent Object, we should follow Spring Data REST best practices.  The object should be created first (via POST), then relationships established (via a PUT).
      • Updating Relationships for existing Objects (via PUT)
        • Whenever we are updating links/associations between objects (via PUT requests), both resources (objects) already exist.  Therefore, we can align with Spring Data REST best practices and send a PUT request (whose request body is the list of URIs to link to, and whose request content type is "text/uri-list").
        • SIDENOTE: If we tried to apply the same query parameter exception to this scenario, the result would be a PUT request with an empty request body (as the link/association would be sent as a query parameter).  
  • We did not get to any of the below topics (as discussion went long).  Below notes are carried over from last week.  Any updates or requests for more feedback should be made on Slack.
  • Angular Team Updates (Art)
  • REST Team Updates