[FOLIO-1965] API design for deletion prevention Created: 12/Apr/19 Updated: 25/Jan/23 Resolved: 25/Jan/23 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P2 |
| Reporter: | Marc Johnson | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | potential-decision, tech-debt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||
| Sprint: | |||||||||||||||||||||||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||||||||||||||||||||||
| Description |
|
In order to support the following user experience during deletion, with usage checks implemented in the backend
At the moment, the checks for usage tend to be performed by the UI. We need to decide:
Assumptions
Context Some conversation around this topic has already happened on
|
| Comments |
| Comment by Marc Johnson [ 12/Apr/19 ] |
|
It seems the most urgent aspect of this is to decide on an API design for how a client can determine if a record can be deleted. I did some quick searching and it appears that this isn't a common pattern in API design, so there appears to be limited guidance available (or I'm not searching for it well). I imagine most systems either do client based checks or refuse deletion after confirmation. Julian Ladisch has proposed adding a nested endpoint to records named /deletable for example /loan-policy-storage/loan-policies/[loanPolicyId]/deletable What are people's thoughts about this idea? Are there any viable alternatives (e.g. a property or properties within the record)? |
| Comment by Aliaksei Chumakou [ 16/Apr/19 ] |
|
Marc Johnson From my experience API usually checks delete availability for the item at the time of DELETE api request, and in case of deny sends error response with some additional data that could be helpful on UI to show a valuable message for end user. |
| Comment by Marc Johnson [ 16/Apr/19 ] |
|
Aliaksei Chumakou Thanks for your comments
That fits with my experience. There is an assumption in the above, that any checks performed prior to deletion are also performed during deletion. I will try to make that more explicit. At the moment, the standard resource types allow DELETE to respond with 400 with a plain text body. Reviewing whether that is sufficient is likely part of this decision. And I agree, those two issues are related to this topic.
Indeed, it does not, the deletion itself could still fail as the circumstances have changed since the pre-check. |