Issues and Decisions

Overview

Currently when persisting any data in CPS the data validation is performed using the yang schema and upon successful validation the data is stored in CPS DB. But in case the data validation fails a 500 response is returned by CPS.

...

This is not very helpful for the user as it does not provide proper information about the root cause of failure.

Proposal

The idea here is to have a mechanism to validate the data and throw an appropriate response with message, before without the data is being persisted in the database. This validation check is not meant to be limited for to new data but should also extend to sub-parts sets of a larger data set, such as data used in case of an update operation. So based on this the following approaches are proposed to perform a validation on data:

• A new endpoint to validate the JSON payload against an existing schema in CPS DB, this endpoint will only validate the data and never persist it.
• A dry-run flag in the existing CPS API's which would validate the data and return a response containing the details of validation failure. This flag can be implemented to multiple CPS APIs such as POST (Create a Node), PATCH (Update a Node) and PUT (Replace a node), where we can validate the entire data or parts of data and return the exact point of failure in the validation as part of response.

Implementation Ideas

In either case the endpoint should return a REST RESTful response with appropriate response code and message. 

• Response Code: 400
• Response Body: a JSON response providing details about the failure. (response body format to be finalized)

List of impacted APIs if dry-run flag is introduced

{
"status": "400 BAD_REQUEST",
"message": "Data Validation Failed",
"Schema node with name "Node" was not found 
under (urn:ietf:params:xml:ns:netconf:base:1.0)data." 
}

Example

The following example shows the expected changes to existing APIs to implement a dry-run flag:

Sub-tasks

The following APIs:

• Create a Node
• Add List Element

would return a 500-response code in case of Data Validation failure. This is in clear contradiction to the details mentioned in CPS Exceptions and REST APIs HTTP Response Codes documentation. This has been identified as a bug and was fixed in the following patch Fix "Create a node" and "Add List Elements" APIs response code · Gerrit Code Review.

References:

• CPS Exceptions and REST APIs HTTP Response Codes
• 400 Bad Request - HTTP | MDN (mozilla.org)
• A good article explaining concept of dry-run: https://dx.apiture.com/docs/api/concepts/dry-runs/