feat(generator): emit typed JSON parsing and handle void/non-JSON responses

[cstrnt]

Only JSON-parse when the response content-type is application/json and emit an explicit typed const data = response.json() as .... Fall back to response.body for non-JSON responses and omit the data field for void responses. Update generated examples, fixtures and generator tests (add empty_response sample) to match the new output.

fixes #55

[terev]

@cstrnt Thanks so much for this, it looks like a much more correct way to handle decoding response data. Its too bad this hasn't been given a look yet. I wonder if it'd help to try requesting another review or tagging the pending reviewers?

[cstrnt]

@terev I mean sure, that would be cool @facundobatista @Blinkuu @DefCon-007

[terev]

I noticed that this pr does actually change the runtime behaviour of the generated client slightly. The behaviour change exists when using a client generated from this branch to perform a request, from which a response is returned that contains an unhandled status code. In the case that the response contains valid json, there is no difference in the runtime execution. However, if invalid json is returned the operation method throws a parsing error. Whereas, with a client generated with 0.4.1, the parsing error is swallowed and the body value is returned as is.

The parse error seems like desirable behaviour when the status code is included in the handled set of status codes where the body is expected to be json encoded.

[2Steaks]

Thanks for this PR!

We have requested changes to avoid changing the response signature too much.

[2Steaks]

Could we look at keeping the try/catch fallback to the response.body to avoid breaking existing scripts.

let data: GetExample200 | string

try {
  data = response.json() as GetExample200
} catch {
  data = response.body as string
}
return {
  response,
  data,
  operationId: 'GetExample',
}