RE: No validator in 200 response for conditional update

> From: Julian Reschke <julian.reschke@gmx.de> on November 6, 2018 11:52 PM
> > In general, since the spec says that server "MUST NOT" send an ETag in
> some case so in order to comply with the spec we must implement that logic
> and it does not matter if it is a corner case or if it may happen only once in our
> API. In reality it is actually not an edge case and happens quite often (up to
> single digit % of all requests in high volume concurrent scenarios).
> 
> Are we talking about the same thing?
> 1) It needs to be a state-modifying request,
> 2) That comes with a validator,
> 3) The validator doesn't match, but the current state of the resource does.
> So this only happens when multiple clients do concurrent updates of a
> resource, and write the same content.

Correct.
Duplicated request from other clients for desired end-state that is already achieved.

> It would be interesting to understand why this happens so frequently - can
> you provide more information about the type of the server/service?

It happens in a typical message-based architecture where components exchange messages and some of them are state changes.
All our state change requests carry If-Match for validation purposes.

Why duplicated updates?
Because components are not just ours, some of them are 3rd party, some are behind bad/geo-long networks.
So, messages in order to be guaranteed, can be delivered one or more times.
Network slowness and errors result in connection terminations which lead to retries and retries lead to state change request duplicates.
This happens pretty often (monthly or so).
But during such network congestions it can be pretty high number of message duplicates.

> You always have the choice of not replying with 204 but with 412, in which
> case the server logic would be simpler, but clients would need to do more
> work.

Sending back 200 from the state management endpoint makes sense since desired state is already achieved and it will reduce infra pressure because clients will move forward with such success updates and also less retries/error handling will be happening.

Thanks, Vladimir

Received on Tuesday, 13 November 2018 22:39:33 UTC