Pet Store is serving up teapots

[philsturgeon]

Hey Daniel! Trying out this awesome thing and getting teapot responses instead of valid mocks:

docker run -p 8000:8000 danielgtaylor/apisprout https://raw.githubusercontent.com/OAI/OpenAPI-Specification/OpenAPI.next/examples/v3.0/petstore.yaml

Responses:

http --json GET http://localhost:8000/pets
HTTP/1.1 418 I'm a teapot
Content-Length: 21
Content-Type: text/plain; charset=utf-8
Date: Fri, 27 Jul 2018 14:23:04 GMT

No example available.

Any ideas? The --json switch sets Accept: application/json which I assume is how you determine the responses. Had the same problem in Postman.

[danielgtaylor]

@philsturgeon the petstore.yaml document is missing examples. I don't yet generate fake data based on the schema, so for now you need to provide an example or examples to get anything back.

I'd like to add schema -> example generation code, but it's never going to be anywhere near as good as a real example. Even the popular json-schema-faker package for Node suggests adding additional hint fields to the schema because of the same reason.

It might be helpful if you could provide examples of what sort of response you would expect from the linked petstore spec.

[philsturgeon]

Ah of course, my mistake. I'm so used to tools like ReDoc just shoving "string" in for strings, etc, that I'm used to everything working. I was just trying to get a hello-world done with a URL using any schema from anywhere.

Using one that's been resolved through Speccy (oas-kit under the hood) I get this:

docker run -p 8000:8000 -v /Users/philsturgeon/src/hackathon-apis/generated/specs/airlock/openapi.yml:/api.yaml danielgtaylor/apisprout /api.yaml
2018/07/27 17:40:58 expected prefix '#/components/schemas/' in URI '#/paths/~1v1~1servers/get/responses/200/content/application~1json/schema/properties/meta'

Attempting to use a sample file from a friend which does have examples, I'm getting this:

▶ docker run -p 8000:8000 danielgtaylor/apisprout https://raw.githubusercontent.com/hskrasek/conference-api-docs/master/specs/openapi.yaml
2018/07/27 17:42:42 error unmarshaling JSON: Error while unmarshalling property 'components' (*openapi3.Components): Error while unmarshalling property 'responses' (*map[string]*openapi3.ResponseRef): Error while unmarshalling property 'content' (*openapi3.Content): Error while unmarshalling property 'schema' (*openapi3.SchemaRef): Error while unmarshalling property 'properties' (*map[string]*openapi3.SchemaRef): Error while unmarshalling property 'items' (*openapi3.SchemaRef): Error while unmarshalling property 'discriminator' (*string): json: cannot unmarshal object into Go value of type string

It's a valid file according to Swagger Editor.

Got any sample files around I can use which will work? I want to verify the functionality so I can merge your openapi.tools PR.

[danielgtaylor]

These look like bugs in the underlying parser library. For now I have opened:

• References outside #/components/... fail to parse getkin/kin-openapi#24
• JSON Schema discriminator fails to parse getkin/kin-openapi#25

I'll swing back and provide an example as I have time later. May also try to tackle some of the issues above when I get some time, too. I think the discriminator one is an easy fix.

[philsturgeon]

Thank you. I've merged it up onto openapi.tools now outta trust. :)

[johnrhunt]

Arg, not much movement on Kin - are there any other libs you could use @danielgtaylor ? Unfortunately I'm not a Go hacker..

[pmundt]

@johnrhunt @danielgtaylor I just ran into this same issue and came across this blog post. This would seem to be a point of difference between the Swagger specification and OpenAPI 3.0. While arbitrary strings for the reference object are valid Swagger, they do not seem to be so under OpenAPI 3.0, which places them clearly under components/schemas - hence the error (earlier versions of the Pet Store API placed these under 'definitions', rather than components/schemas, and no longer work, either). I would suggest given OpenAPI 3.0's view on this topic, this should not be considered a bug outright, but some additional guidance to assist people with migration would be helpful, too.

[AbhimanyuG]

@pmundt I see your point however all resolvers I came across generate such arbitrary references:
$ref: '#/paths/...
If there's a better resolver which strictly adheres to OpenAPI 3.0 standards, this wouldn't be a problem but my search hasn't concluded any such tool so far.

If someone knows such a resolver, please let us know.