Closed Osipion closed 7 years ago
One thing that caught my attention. "Every response should have a schema as per the description in the swagger spec over here". In the example where you are referencing a model for 401 to an internal server, you are directly referencing it. I think it should be inside a schema, the way 200 is defined.
"401": {
"schema": {
"$ref": "http://internalserver/api-governance/shared/responses/401.json"
}
}
I would also recommend, reading this section of the documentation that talks about default responses and processing negative responses.
In essence, the generated would not throw an exception for 401 and 404 but would deserialize as per the schema defined for that response. However, the return type of the method would be the common ancestor of all the deserializable responses (200, 401, 404) which in most cases would turn out to be an Object. (just wanted to let you know).
@amarzavery thanks for the response. I will try moving the refs inside a schema node when I'm back on site tomorrow. The behaviour described in your second comment is desired (strongly typed would be nice, but we can make do :-)) - we want to use AutoRest to generate test clients. Thanks for the tip though.
For example for an operation Members_Get, in 200 you return a model named "Member" and you described 401 with a schema that returns a model named "FooError". So in your definitions section you will have these model definitions. If they share a common parent then that would be the return type of the method. However, in most cases I don't see that these model types (Member and FooError) would have a common parent. However in languages like C#, Java, javascript all objects inherit from "Object". Hence the return type in most cases would end up being an Object. I am not sure if you would want that as your method signature in strongly typed languages.
Ah OK - apologies for deleting the question, I realised it was answered in the document you linked to. Defining a default schema in the swagger would allow for a common base type, and that base type would be the return type of the api methods? Otherwise they'd probably inherit from System.Object.
@amarzavery I've taken a look at the response references in more detail. The OpenAPI spec says that if the schema node "does not exist [in the ResponseObject], it means no content is returned as part of the response." In actual fact, the $ref doesn't point to a schema for the response, but to the ResponseObject definition itself:
{
"description": "A response"
}
This appears to be valid according to the json reference spec, and the swagger editor is OK with it.
In actual fact, the $ref doesn't point to a schema for the response, but to the ResponseObject definition itself
In that case, remove the $ref as it makes no sense. Just provide the description.
Hi @Osipion. Can this issue be closed?
Hi @tbombach - we'll, I've worked around the issue by first processing the spec with the npm package json-refs, which resolves the remote json fragments. We use these fragments because we support a different API for each product domain, but share error definitions across them. It's up to the contributors as to whether this behaviour is a bug or by design, but a better exception message would be nice :-).
Note that there is a difference between the (very liberal) JSON refs specification and Swagger, which has stricter rules for where refs are allowed and what they may point at. As far as I can derive from the discussion above, the issue encountered was due to this discrepancy.
I will close this issue, but feel free to post a (minimal) example of both main and referenced Swagger file that adheres to the Swagger spec but crashes AutoRest and I will gladly reopen. :)
@olydis Looks like $refs
can be used other than to reference schemas although I don't know if that includes my example. The spec seems a little confusing on where $ref
may be used - from what I can work out:
$ref
to point to a response definition, which was my problem.The spec also says:
parts of the definitions can be split into separate files, at the discretion of the user. This is applicable for $ref fields in the specification as follows from the JSON Schema definitions
Which suggests a relatively arbitrary use of JSON refs is supported, and the official swagger editor allows it.
I guess the problem would be that it's difficult to work out what the error is when AutoRest rejects it since other swagger tooling doesn't highlight it. Would a better exception message be possible?
Absolutely correct. Looking at your examples again, it seems I was drawing the wrong conclusions from the discussion... your Swagger is perfectly fine 👍 but using the current AutoRest, both of your examples work for me (after pointing the external URLs to some files/URLs that are accessible)!
Do you have a counterexample (with URLs that work for me - or post the referenced swagger)? :)
AutoRest fails to generate a client for the following swagger (refs point to documents on an internal server):
The stack trace is:
If the error response definitions are removed (like so):
Then I get:
If I remove any refs that point to external documents, then the client object model is generated successfully.