While working on Blubberoid and its OpenAPI specification, the benefits of using JSON as the primary serialized config format are starting to stack up:
1. OpenAPI specifications can provide descriptions of request and response objects for a given endpoint and accepted media type, but object schemas for a YAML media type are not supported; this is because:
2. There is no media type for YAML [[ https://www.iana.org/assignments/media-types/media-types.xhtml | registered with IANA ]]. The closest I found to even a semi-official type is [[ https://www.ietf.org/mail-archive/web/media-types/current/msg00688.html | a proposal on the IETF mailing list ]] which lacks a follow-up.
3. OpenAPI specifications use JSON Schema as a means of defining acceptable data objects, but it does not work with YAML media types (again, there isn't a YAML media type). We could potentially have Blubberoid support JSON as well as YAML, but leaving the internal YAML-based parser would necessitate either duplicating the field descriptions and validation patterns, or writing our own JSON Schema generator that works from the `yaml` and `validate` field tags.
4. Switching to JSON Schema for our own validation and configuration policy has potential benefits as well, namely one less external dependency (validator) and extensible schema rules.
Note that we may be able to retain YAML support for human-written configurations as well as support YAML on CLI and Blubberoid interfaces by converting YAML to JSON before unmarshalling. However, it isn't yet clear whether this can be done in a sane and efficient manner.