API Error codes

[Dor_Marcovitch]

hey,

i am just starting to work with the API, something really frustrating with the return messages with errors.

below is what i get when trying to create an object, what i was excepted as a programmer that each individual error type will have a different error code that i can compare, and not to "parse" the error message to understand what is the type of error message to handle.

do you think different ? 

do you get different responses?

APIResponse({
"data": {
"code": "err_validation_failed",
"errors": [
{
"message": "More than one object named 'FTP' exists."
}
],
"message": "Validation failed with 1 warning and 1 error",
"warnings": [
{
"message": "The port is already used by another service."
}
]
},
"error_message": "code: err_validation_failed\nmessage: Validation failed with 1 warning and 1 error\nwarnings: \n- message: The port is already used by another service.\nerrors: \n- message: More than one object named 'FTP' exists.\n",
"res_obj": {
"data": {
"code": "err_validation_failed",
"errors": [
{
"message": "More than one object named 'FTP' exists."
}
],
"message": "Validation failed with 1 warning and 1 error",
"warnings": [
{
"message": "The port is already used by another service."
}
]
},
"status_code": 400
},
"status_code": 400,
"success": false
})

[PhoneBoy]

Ultimately, the API is returning the expected result in this case.
There are two issues, ultimately (one warning, one error).
Whether that result is optimal or not is a different question.

[Art_Zalenekas]

Dor,
You don't have to parse the message key to know what is wrong. The .data.code tells you the error code. Out of that error code, you might have different messages, which in your case produces two (2) messages. 1) Errors array ["More than one object named 'FTP' exists."] (.data.errors[].message), and 2) Warnings array ["The port is already used by another service."] (.data.warnings[].message).

Now you need to know and understand Check Point product to understand the validation aspect here, but you can choose to ignore warnings and/or errors if that is what you want/need. Another aspect is settings an object which already exists. You will need to use the parameter set-if-exists, or else you will get an error as well. My point here, is you need to know what you are trying to accomplish.

Additionally, in documentation, we do give for each API call our Error codes. Feel free to use those as your Enum.

https://sc1.checkpoint.com/documents/latest/APIs/#cli/add-service-tcp~v1.8%20

Please let us know if you have any questions or concerns.

Good luck!

[Dor_Marcovitch]

What i mean is that the .data.code value of err_validation_failed is too general to know that the validation error is duplicate name exist. Unless you tell me that this error means that is the case but basic logic tells me this is some general validation error and many others can be. 

To solve the case programmatically i will need to parse woth regex the message to see the validation error is about duplicate name. And try to create an object with another name. 

[Dor_Marcovitch]

another example when trying to add "8731_tcp" object:

error_code: code: err_validation_failed
message: Validation failed with 1 blocking-error
blocking-errors:
- message: Object name must start with a letter

[_Val_]

How about you call it (supposedly service object) tcp_8731?

[Dor_Marcovitch]

this i what i do, basically i am migrating configuration, and need to "act" based on the validation error.

[Bob_Zimmerman]

It would be nice to have more granular errors, absolutely.

In the case of config migration, you can skip a lot of headache using 'show objects filter <expression>'. You can use it to check for the actual values as well as the names. If there's no object for the semantic value you're trying to build, check for your proposed name. If there's no object for your proposed name, create it. If there's an object using your proposed name, go to an alternate name (like adding an _# to the end of the name and incrementing the # as needed). Of course, including a migration identifier (like a project number or ticket number) in the proposed name all but guarantees you won't have name collisions.

All the 'show objects' API calls cost time, sure, but they help preemptively ensure correctness.