A situation arose in the work that does not fit well into the traditional REST: there is an entity (monetary transaction), which after creation can be updated only once (correctly completed or canceled). Those. The entity is processed as follows:

transaction [id=<uuid> state=pending] (волшебное обновляющее действие путем воздействия на API через HTTP) transaction [id=<uuid> state=completed] или transaction [id=<uuid> state=cancelled]

Of course, I can declare a PUT controller that will catch the {"state": "completed"} format payload and apply it to the transaction if it has not yet been completed in one way or another. However, this approach seems to me frankly a crutch; it seems to me that PUT requests in the generally accepted understanding of REST should not be blocked by such complex validation rules. Is there a more beautiful solution inside the generally accepted vision of REST?

  • Why not POST transaction/{uuid}/complete and POST transaction/{uuid}/cancel ? - Nofate ♦
  • @Nofate that the resource actually is not created. Well, that there is no real such sub-resource, and the resource itself implies the essence and should be expressed by nouns. - etki
  • As for me, this is a lawyer of the rules. You can think of it as creating a transformation for a state machine that translates the transaction/{uuid} resource into one state or another. Moreover, the transformation can still be a very real resource and run asynchronously. If you pick on a noun, it can be POST transaction/{uuid}/completion and POST transaction/{uuid}/cancellation - Nofate ♦
  • The GitHub API for changing the Issue state, for example, uses the approach you suggested, but not with PUT , but with PATCH . - Nofate ♦
  • 2
    Here is a long article about Good Practices and there’s nothing besides my version and yours either. - Nofate ♦

0