Responses Object keys must be strings?

[mabar]

Responses Object spec says that: This field MUST be enclosed in quotation marks (for example, “200”) for compatibility between JSON and YAML (https://github.com/OAI/OpenAPI-Specification/blob/157a4c81ae537ef793b2bee368bc00d88b461de8/versions/3.0.2.md#patterned-fields-1)

Is it really needed?

Json only allows strings as keys and at least in PHP numeric keys are auto-encoded to strings.

Yaml allows both, but in PHP numeric keys are always type-casted to an int, like 200, instead of "200"

• proof of PHP array typecasting - https://3v4l.org/F8slo
• my tests showing how keys are encoded into json and yaml - https://github.com/orisai/openapi/blob/314b0ce647bd5b5878eced14cfe67b82915d1f12/tests/Unit/Spec/ResponsesTest.php#L109-L139 (current build failures are related to caching issues, code is correct)

Because it is probably not possible to create workaround for this in PHP, we could solve it only by adding a flag to yaml encoder to make integer keys strings (in case array is not auto-indexed from 0)

But the preferred way would be to remove string key requirement from specification.

[hkosova]

This was previously discussed in #2147 (comment) and #2171 and the decision was to keep string keys.

[mabar]

There is already quite a lot of validations dependent on multiple properties or even multiple objects, would it be a big problem to add one more in next major? So far I found no PHP library that prints codes as strings, because it's very hard to do...

[mabar]

Maybe spec could encourage use of json for cross compatiblity instead of yaml? json works well in practically every language, unlike way more complex yaml.

[handrews]

Maybe spec could encourage use of json for cross compatiblity instead of yaml? json works well in practically every language, unlike way more complex yaml.

@mabar the OpenAPI specification is defined as a JSON object that can be encoded as either JSON or YAML, so this is pretty much already the case. This is, in fact, why the keys in YAML need to be a string as the issues linked by @hkosova note.

Any time you are maintaining JSON compatibility in YAML (not just for OpenAPI), you have to convert non-string keys to strings before serializing to YAML.

[mabar]

Well, some work is being done on Symfony side to solve this problem in PHP.

I hope assumption that all numeric keys could be encoded as strings in yaml, except in arrays that are auto-indexed from zero, will work.

Otherwise we would have to write a whole new yaml encoder with AST support for PHP, to be able explicitly tell, which keys should be strings.

[lornajane]

This has been inactive for a while and I don't think it can be improved by changes in OpenAPI itself, so I'm closing this issue. Thanks for the great discussion, some really useful information in this thread.