21. June 2016
With great pleasure Dataloy presents API 3.1
Issues resolved - listed by user story
Highlights of this Release:
Highlights of Dataloy API 3.1
DLP-322
Possibility to extend the returned fields of a given end-point asking for each sub-object to return its "default" view. This can be done specifying in the JSON message of the "fields" property to attach to the HTTP header the property "all":"*".
For example with the following JSON attached to the VoyageHeader end-point:
{ "company":{ "companyCurrency":"*" }, "voyage":{ "all":"*", "portCalls":{ "all":"*" } } }
it will return:
the companyCurrency attribute of the company of the VoyageHeader, attribute normally not returned from the VoyageHeader end-point
the default view attributes of voyage and portCall objects
DLP-366 and DLP-369
Ensured transnational context during any POST and PUT resources
DLP-401
Introduced a generic mechanism to invoke pre-process checks before the deserialization of JSON objects
Created pre-process components for Cargo and CargoPort objects.
The following control are done when a Cargo is POST or PUT:
For not lumpsum cargo:
- Changing cargoQuantity in a cargoPort does not trigger any calculation on cargoQuantity of other cargoPort.
- The cargoQuantity at cargo level is calculated summing the cargoQuantity of loading ports
- it is not possible assign freightRate in both discharge and loading ports.
- The cargoQuantiy used for calculations are those in cargoPort, cargoQuantity at Cargo level is not used in calculations
- Freight and freightRate used for calculations are those in cargoPort,
- API will not use stowageFactor and weightFactor from commodity
For lumpsum cargo:
- cargoQuantity and freightRate must be assigned at Cargo level
DLP-411 Karl