I really like this concept, it definitely makes sense for certain operations to use a POST to distinctly represent intent such as the example with GitHub’s merge resource. With the example provided of updating the destination, through a traditional REST API this could be achieved with a PATCH request containing just the destination and allow the backend to then compute the status internally after that update. I would go further to make the status a read only field that can only be updated through the internal logic of the backend this would achieve the same benefits as an intent based endpoint of confining the logic solely to backend source of truth without having to creating multiple intent based endpoints - what if the status was dependent on multiple fields within the model would this not introduce bloat to the client facing API to update each field through its own intent based endpoint?