CoderDojo / community-platform

Zen, the CoderDojo Community Platform!
https://zen.coderdojo.com
MIT License
121 stars 55 forks source link

Event creation form: saving an event #1262

Closed Wardormeur closed 4 years ago

Wardormeur commented 5 years ago

Epic: https://github.com/CoderDojo/community-platform/issues/1230#issuecomment-483288199 Design a set of API endpoints to be able to save an event, from the events-service perspective. This doesn't take into account the middleware. New event (internal): POST /events Edit event (internal) PUT /events/:id (Change state )? (internal) PATCH /events/:id/status

Separating the content of the event from its status could simplify the flow. As an example, that means that publishing an event is a different action from saving it. That allows us to avoid having to handle the status switch as part of the event saving handler; as long as we exclude the status from the event saving payload. Cancelling would just become a simple PATCH /events/:id/status {status: cancelled } or PATCH /events/:id/status/cancelled, rather than doing validation on the whole event. The drawback comes from requiring 2 HTTP requests when moving from draft to publish (save, then change state). As well, it's a bit weird to be able to change the event definition without changing its state from a functional perspective : as much as changing the event definition to cancel an event makes no sense (and will likely be forbidden), changing from a draft to a published event will likely involve a change of the data. Thoughts @ArayB ?

ArayB commented 5 years ago

With a PUT /events/:id we'd be overwriting the event definition with the values provided from the frontend, as part of that I think it would be fine to include a status change. So if you are going from draft to publish you would only need to do a PUT which included changing the status (as well as any other changes to the event).

For just changing the status we could do something like PUT events/:id/status but that does open us up to having to add multiple endpoints for anything we want to change in a similar way. We could also do a PATCH events/:id endpoint that just takes the changes made and applies them.

So something like: PUT events/:id for full event editing (which could include a status change) PATCH events/:id for partial editing (initially only editing status)

RFC for json merge patch shows how that might work.