Autorest: TestServer inconsistency on "null" test

[lmazuel]

Let's take this file:
https://github.com/Azure/autorest.testserver/blob/master/swagger/body-integer.json

And the int_getNull operation. Doing a call actually return no body with a 200:

The Swagger explains that it produces "application/json", but an empty content is not a valid JSON, meaning the Swagger does not reflect the RestAPI...
Solution is to either change the testserver to put content-type "text/plain", or to put the four characters null (valid JSON).

I try to tighten a little my deserialisation, just to start thinking about future XML parsing in Python, and this kind of details blocks me :(

Not urgent, but should be addressed.

FYI @amarzavery

[olydis]

yep I wondered WTF that empty content instead of null is all about but the hard truth is that the C# generated code has encoded null as empty string since I got here, I have no clue why this was done like that. At this point, it would be a slightly unpredicatable breaking change to change that behavior, so not sure what we can do... but I agree 100% that the testserver should test for the right thing, even if that means C# tests have to be skipped or changed

[olydis]

@lmazuel it turns out we actually rely on that (some services apparently return an empty response for null), and it gets even crazier: we found that application/json does actually not specify anything more than JSON objects and arrays, not primitive values including null. I've created this document to keep track of how we interpret stuff, so we can have consensus across generators.

[lmazuel]

@olydis Spec update https://tools.ietf.org/html/rfc7159

A JSON text is a serialized value. Note that certain previous specifications of JSON constrained a JSON text to be an object or an array. Implementations that generate only objects or arrays where a JSON text is called for will be interoperable in the sense that all implementations will accept these as conforming JSON texts.

A JSON value MUST be an object, array, number, or string, or one of the following three literal names:

  false null true

[fearthecowboy]

Good to know they have a revised RFC.

Still present

"A JSON parser MAY accept non-JSON forms or extensions."

Bastards. Of course they can.

At this point, we've implicitly supported empty body as null; I don't know if in practice that has made a difference.

I realize that we are dancing on the line here, but ...

[lmazuel]

@fearthecowboy Python JSON parser refuses an empty string as a correct JSON. So I have this hack:
https://github.com/Azure/msrest-for-python/blob/3d961f81eca2c577c35e5e05d7894f0ce7b2e2a2/msrest/serialization.py#L1066-L1067

Honestly it's no big deal, and I can live with that. So I'm fine with the interpretation doc of @olydis

[fearthecowboy]

Yeah; I suspect we're going to have a couple of 'hacks' in some languages to support it. I think Java has some real pain coming up 😿

[olydis]

I don't think any language supports this without hacks, including C# 😉