REPLACE endpoint for more reliably replacing events

[johan-bjareholt]

So it's already possible to replace events by setting the "id" property in the /insert endpoint.

So why would you want to have a separate /replace endpoint?

• Because /insert does not fail if the "id" does not exist, it creates a new event
• If one out of many replaces in /insert fails we have no idea what actually happened, we need to do fetch the events after to be certain which should be unnecessary
• Any other reasons, put a comment below and I'll add it to this list

I don't think this is a high priority task right now, might be in the future if we get a use-case which replaces a lot of events.

Resources:

• Discussion on aw-server-python PR by @leoschwarz Expose replace event endpoint aw-server#57

[leoschwarz]

My main reason for the linked PR was that I think at that time there was no event updating endpoint, but since it's possible I don't see a stringent need for it anymore. Also maybe it should be named update if it were to be added.

If one out of many replaces in /insert fails we have no idea what actually happened, we need to do fetch the events after to be certain which should be unnecessary

One could change

aw-server-rust/aw-server/src/endpoints/bucket.rs

Lines 142 to 149 in 642a531

	Ok(events) => Ok(Json(events)),
	Err(e) => match e {
	DatastoreError::NoSuchBucket => Err(Status::NotFound),
	e => {
	warn!("Failed to create event(s): {:?}", e);
	Err(Status::InternalServerError)
	}
	},

to return per event success/failure information in the response body (and set success in the header if everything succeeded, failure otherwise). For example, you could add an additional "success": field to events inserted, the details of this would be something to think about if this approach is chosen.

So I think it's mainly an API design choice whether to have this endpoint or not (simpler vs lower number of endpoints).