I'm developing an API for events management. I have the basic GET and POST methods but now I have to deal with the event resource edition.
A user can edit all the event information using:
/event/:eventId
But also it can cancel the event (not deleting it, but changing it's status
property).
I've thinking on using this endpoint:
/event/:eventId
and send a body with only the new status
property value.I think this is a good approach but then I have noticed that the status can only be set to CANCELLED
, the other allowed status for the event are changed automatically in the business logic in certain cases.
So sending the status
field doesn't make sense at all if you only can change it to one possible value.
Therefore, is it possible and not a bad practice to send no body to a PATCH method? Thanks.
My question is if a body is mandatory when using a PATCH if it's redundant. Read my question again please, thanks! If that's the only change you can do, then yes. The operation is a partial update and sending the body will be redundant, so you could just omit it.
As part of a POST, PUT, or PATCH request, a data payload can be sent to the server in the body of the request.
PATCH is defined in RFC 5789: The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request- URI.
I would suggest to make PATCH endpoint to /event/{eventId}/status. There is no need to put payload to your PATCH request, payload is optional.
API should be meaningful to end user. With PATCH you are letting user know that you want to do a partial update on the event record for provided eventId and the attribute you want to perform action is status.
In addition, make sure your API doc provides the detail that status will be set to CANCELLED by default. And in future, if required you can scale API by adding payload {"status": "CANCELLED | ENABLED | .." }
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With