how to design REST API to ask server to wait for resource version to arrive on GET requests?-CodePudding

I work on splitting monoliths into microservices. With the monolith, I had a single source of truth and can just GET /resources/123 right after the PATCH /resources/123 and be sure that the database has the up-to-date data I need.

With microservices and CQRS in place, there is a risk that the query service has not seen yet the latest update to the record when I perform a GET request.

What is the best or standard approach to making sure that the client receives back the up-to-date value? I know that the client may compare resource versions that he receives after PATCH and after GET and retry requests, but is there a known API design to tell the server something like GET /resources/123 and wait up to 5 sec for the resource version 45 or bigger to arrive?

CodePudding user response：

Generally a better design might be for the PATCH request to delay its own response, if that's an option.

However, your GET request can also just 'hang' until it's ready. This generally feels like a better design than polling.

A client could indicate to the server how long it's willing to wait using a Prefer: wait= header: https://datatracker.ietf.org/doc/html/rfc7240#section-4.3

This could be used both for the GET or the PATCH request.

I don't think there's a standard HTTP way to say: this resource is not available right now, but will be in the future. However, there is a standard HTTP header to tell clients when to retry the request:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After

This is mainly used for 429 and 503 errors but neither seem appropriate here.

Frankly this is one of the first thing I've heard in a while that could be a good new HTTP status code. 425 Too Early exists but its a different use-case.

CodePudding user response：

Since a PATCH request allows a response body, to my mind there's nothing wrong with the response including the object after patching. The requestor who sent the PATCH can use the response in lieu of a GET; for others, the eventual consistency delay for the GET isn't observable (since they don't know when the PATCH was issued).

CQRS means to not contort your write model for the sake of reads. If there's a read that is easily performed based on the write model, that read can be done against the write model.