Why we do not have pure JSON in the body of API responses

[robin-checkmk]

This was originally posted by @kain88-de in #153 (comment).

Maybe a quick note as a developer of checkmk. We do care about using JSON in the API. That we do not have pure JSON in the body of API requests is also annoying for the developers of checkmk. There are a few historical reasons why it is not straight forward to make the raw_value field a json string.

Workaround

The string in raw_value is pure python. You can convert it to a python object using ast.literal_eval, like the current api code does. Converting it back is done using repr, the linked code example masks secrets.

Why can we not just use JSON?

There are two classes that deal with rules ValueSpecs and RuleSpec.

Rulespec is just a thin wrapper around a python object, stored in the variable value. The Rulespec is used to determine if a rule applies to a given service/check plugin. The check plugin later only gets the value. We have a large number of plugins that behave differently based on the type of value, example in the gcp utils. The check plugins always worked like this. Since pretty much all mkps rely on this behavior we cannot change it.

ValueSpecs are kind of a schema definition for RuleSpecs, kind of because they also do a lot more. The API only uses them for validation. Because we cannot change the type of RuleSpecs without breaking almost all MKPs the API would need to convert JSON-arrays to a python tuple in a parsing step. This could be added. In fact we do have buggy support for parsing JSON. For example here is a bug in the Alternative ValueSpec. Here is an example using Alternative to define different option to configure levels. In that example the length of the tuple decides if you want to apply fixed levels or predictive levels. This is not ideal and also a pain for us developers. Unfortunately a lot of legacy code and MKPs depend on this behavior.

In short touching this is difficult because a lot of legacy code depends on the current behavior and making changes to the python API of RuleSpec of ValueSpec is risky because it might break a lot of existing code from customers.

We really would like to use JSON ourselves. But it is not straight forward to find a solution that works with the constraints we have due to RuleSpec and ValueSpec.

[jupiler]

Well I'm currently struggling with this.
Trying to automate our http rules form which some require regex strings which almost makes it impossible to escape them in the correct formats.

What i was thinking: Would it not be a work around to base64 encode the value_raw and then let the checkmk api decode it when detected a b64 string or just add it as key b64_value_raw?

[msekania]

@jupiler

what about using raw strings (!unsafe) of Ansible. Will that solve the problem?