Design of Orderables and FTAP versioning

1. use PUT /api/orderables/ID, you can update only latest version, attempt to update past version will be rejected. This be verified based on the versionId included in the request body
2. every change will spawn a new version
3. we use a serial integer starting at 1. The version of that uniquely identified thing is something that is bounded by ACID, and therefore should always increase in a predictable fashion.  Note what this means is that when you change an entity (say in the UI), you never increment the version and send it back, that's a function of the write operation on the server from which it was read.

4. OpenLMIS allow any attribute change which is defined in the GDSN and trust that the author understands the effect of that master data in the supply chain.

1. FTAP should reference non-versioned Orderable, Program, and Facility Type.  
2. use PUT /api/facilityTypeApprovedProducts/ID
3. every change will spawn a new version
4. we use a serial integer starting at 1. The version of that uniquely identified thing is something that is bounded by ACID, and therefore should always increase in a predictable fashion.  Note what this means is that when you change an entity (say in the UI), you never increment the version and send it back, that's a function of the write operation on the server from which it was read.

How to retrieve the historical versions?

1. Orderable has version property and we can get version by calling e.g. GET  /api/orderables/ID?versionId=5. Migration set the version to 1 by default.
2. FTAP has version property and we can get version by calling e.g. GET  /api/facilityTypeApprovedProducts/ID?versionId=5. Migration set the version to 1 by default.