21. June 2016
With great pleasure Dataloy presents API 3.1
Issues resolved - listed by user story

Highlights of Dataloy API 3.1

It is possible to extend returned fields of a given endpoint by asking for each subobject to return its "default" view. It can be done by specifying in the JSON message of the "fields" property attached to the HTTP header the property "all":"*". For example, the following JSON attached to the VoyageHeader end-point:

{  
   "company":{  
      "companyCurrency":"*"
   },
   "voyage":{  
      "all":"*",
      "portCalls":{  
         "all":"*"
      }
   }
}

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

Ensured transnational context during any POST and PUT resources

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

Port Cost breakdown can now be accessed from portCall.portAgents and further portAgents.portCosts Only a link is included by default so use the following functionality to get all you need in one request: Adjust Number of Fields to be Returned from a Request.

Related Content