DS-3851 initial proposal for the workflow endpoints #20
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a starting point proposal for the contract of the workflow endpoints in the new REST API.
The implementation of a workflow state machine actions is widely debated question and there are lot of discussion about the best way to implement them in a RESTful way or criticism about which implementation is not really RESTful.
This is a good summary of the different possible approaches
http://www.kennethlange.com/posts/Modeling-Workflows-in-REST-APIs.html
these are also useful resource to listen different opinions, pro and contros
https://restful-api-design.readthedocs.io/en/latest/methods.html#actions
interagent/http-api-design#58
https://www.gvj-web.com/blog/custom-actions-your-rest-api
At the end my preferred approach is in the middle between the approach "2. Transition Links" and "3. Transition Subresource" of the above summary.
We have explicit tasks resources that help us to drive the state change. We can POST on such resources and DELETE tasks. At the start I was uncertain about the use of POST but it should be noted that POST doesn't allow the client to expect to be able to make a subsequent GET request on the same resource to retrieve the data that was sent, so it is the right http verb compared to PUT.
On the proposed contract I don't like the way that "command" are executed on the existent workflow action. For instance we have an action state name "editaction" in the dspace xml workflow that can receive two commands: approve or reject. There is no standard way to know which commands are allowed for which action state. I plan to fix that later introducing subresources so that on a specific tasks the client known which are the available commands i.e.
Anyway, I have preferred to share the current contract that we are implementing to provide initial workflow capabilities in DSpace 7 to start the discussion.