Crash when response code is integer

[jgontrum]

Hi!
First of thank you for this project - it is exactly what I need!

However, I discovered a bug that occurred when the response code of a method in the Swagger file is interpreted as an integer.
The error is expected string or bytes-like object.

Example:

swagger: '2.0'
info:
  title: Test API
  version: "0.1"
produces:
  - application/json
basePath: /api/v1
paths:
  /test:
    post:
      operationId: test_api.api.fromurl.post
      responses:
        200: #<---
          description: Returns something

If I use "200" instead, it works.

I discovered that the bug actually happens in jsonschema._utils, where a regex fails to run over the integer. Strangely, other packages that I previously used to interpret Swagger (like connexion) also depend on the jsonschema package and they work fine.

I tested this on Python 3.6.1 on OS X 10.11.6. The version of jsonschema is 2.6.0 and of prance 0.5.1

I would really appreciate it, if you could investigate this bug!

[jfinkhaeuser]

Thanks!

Actually, that's not precisely bug - unfortunately, I might say. I've come across this before, and you may come across this when using AWS in particular.

The thing is, OpenAPI specs are a little vague in some edge cases, and this is one of them.

OpenAPI specs generally provide examples as YAML files, but crucially include the mandate that specs must validate given an appropriate JSON schema. Which means the YAML you can use must be the subset of YAML that also works in JSON. And JSON does not allow any keys that are not strings (YAML allows any object, though the notation for that is horrendous).

So for a strict validation, an integer 200 must raise an error.

I have wondered about a lenient mode to prance that would stringify keys before trying to validate, but I'm not sure that might not have unintended side effects. Would that be helpful, or are you happy to change to string "200" instead?

[jfinkhaeuser]

Mind you, the location of that error might be weird. I'm going to look into it one way or another :)

[jfinkhaeuser]

No, the error location is exactly what I suspected: the JSON validator requires string keys and finds non-string keys.

I've added a non-strict mode as outlined that stringifies keys. I hope that's in your interest :)

[jfinkhaeuser]

Fixed in v0.6.0