Preview Release schedule discussion with Steering Group
Tim will schedule a meeting of core contributors (DuraSpace, Atmire, 4Science) to discuss upcoming release schedule, brainstorm ways to speed up development/review processes and better stay on schedule.
(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".
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 with 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]).
Updating Relationships (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).
This approach is generally frowned upon in REST best practices, as both POST and PUT are expected to specify their data in either the request's body or headers. So, sending a POST/PUT with no body would be equivalent to sending a request to create a new empty object. In other words, the main data of a PUT or POST request is expected to be sent in the body of the request – so, a request with no body is a request that sends no data.
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.
Giuseppe says this wIll be ready for final review by Monday, January 14. He will ping us
ACTION: Anyone who has added past comments (that are now fixed), please go in and resolve your past comments once you've verified the fix. That'll help us figure out what is outstanding (if anything)
ACTION:Tim Donohue will reach out to Andrea Bollini (4Science)to understand whether we can move forward with parameters for now, and update this contract/implementation later. It's unclear to the team why these three tickets are blocked for Spring Data REST alignment, while others that involve links/associations (e.g. PR#37 (Item CRUD) and PR#38 (Metadata Registry)) were approved.
Should we consider fixing all these implementations to better align with Spring Data REST recommendations (perhaps in a future Ticket/PR)?