4 ms·

This does not seem like a reasonable idea in a business-rules sense. the 12345 in http://api.example.com/product/12345 http://api.example.com/product/12345 is p

by bcoates 12y ago

This does not seem like a reasonable idea in a business-rules sense. the 12345 in http://api.example.com/product/12345 http://api.example.com/product/12345 is presumably a SKU, which is the natural key for a product you're selling. You don't get to convert it into a GUID and declare it immutable. If the price isn't effectively fixed, the API client is going to need to generate a quote ('shopping cart'). The API rates the product when the quote is made, and then there is some business rule about how to handle quotes from before the price change. The value-based URL refers to an entity ('SKU-price pair from some time in the past') which has no reasonable use.

ZoFreX 12y ago
If the identifier is an SKU, it seems to follow that to distinguish between different prices one could have an additional "version" identifier? Or perhaps even a more generic on-this-date parameter, in this case representing date of quotation (which then dovetails quite nicely with the expiry mechanisms already built into HTTP).
chris_mahan 12y ago
Besides, the price may be different based on who's asking.
aphelion 12y ago
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.
- SilasX 12y ago
  >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.

by bcoates 12y ago

ZoFreX 12y ago

If the identifier is an SKU, it seems to follow that to distinguish between different prices one could have an additional "version" identifier? Or perhaps even a more generic on-this-date parameter, in this case representing date of quotation (which then dovetails quite nicely with the expiry mechanisms already built into HTTP).

chris_mahan 12y ago

Besides, the price may be different based on who's asking.

aphelion 12y ago

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.

SilasX 12y ago
>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.