So generate immutable ProductState objects that contain all parts of the ___domain model that can change over time, and maintain a mapping from SKU to the correct object.
So GET /product/12345 returns UUID_1 at time A, when details of the offered item change at time B a UUID_2 gets generated and a new GET /product/12345 returns UUID_2.
If you want to be really anal retentive, generate the product state objects with timestamps to compare to the Date header in requests and have a list of product states that have been referenced by a given SKU to traverse through to get correct product details even when the catalog changes between sending and receipt of the request.
>So generate immutable ProductState objects that contain all parts of the ___domain model that can change over time, and maintain a mapping from SKU to the correct object.
But that just recreates the very problem the author set out to solve, which is that you have to send increasingly huge sub graphs of the database with each order.
I assumed the direction he was going to go was to let the client send the at-the-time data back with each subsequent request for time consistency, but require them to pass a server-provided signature to keep them from making up prices, and saving the server from having to keep a time history of every case.
So GET /product/12345 returns UUID_1 at time A, when details of the offered item change at time B a UUID_2 gets generated and a new GET /product/12345 returns UUID_2.
If you want to be really anal retentive, generate the product state objects with timestamps to compare to the Date header in requests and have a list of product states that have been referenced by a given SKU to traverse through to get correct product details even when the catalog changes between sending and receipt of the request.