Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Swagger - Specify Optional Object Property or Multiple Responses

Tags:

swagger

I have an API that either returns the following response on success:

{     "result": "success",     "filename": "my-filename.txt" } 

or something like below upon failure:

{     "result": "error",     "message": "You must specify the xxx parameter." } 

The filename property is only specified if the request was a success, but a message is provided if there was an error. This means the message and the filename properties are "optional" but the result property is required.

I tried defining this response object in a definition as shown below:

"my_response_object": {     "type": "object",     "properties": {         "result": {             "type": "string",             "description": "value of 'success' or 'error', indicated whether was successful",             "required": true         },         "message": {             "type": "string",             "description": "an error message if there was an issue",             "required": false         },         "filename": {             "type": "string",             "description": "the filename to return if the request was successful",             "required": false         }     } } 

But it appears that swagger does not like the "required" attribute and will show the following error message:

enter image description here

When I look at an example from swagger, they have the following layout where there are two different response definitions instead of one.

"responses": {     "200": {         "description": "Profile information for a user",         "schema": {             "$ref": "#/definitions/Profile"         }     },     "default": {         "description": "Unexpected error",         "schema": {             "$ref": "#/definitions/Error"         }     } } 

I could do this, but it appears that one cannot have multiple responses for the 200 error code. Does this mean that one has to use "default" for all error responses, and one can only have a single structure for all erroneous responses, or is there a way to specify that certain attributes are optional in definitions?

like image 452
Programster Avatar asked Jan 08 '15 15:01

Programster


People also ask

How do you pass multiple parameters in swagger?

If you are trying to send a body with multiple parameters, add an object model in the definitions section and refer it in your body parameter, see below (works with editor.swagger.io):

How do you make parameter optional in swagger?

Required and Optional Parameters By default, Swagger treats all request parameters as optional. You can add required: true to mark a parameter as required. Note that path parameters must have required: true , because they are always required. description: Numeric ID of the user to get.

Can I use multiple response examples with Swagger UI?

You can follow this issue for updates. As a workaround, you can specify a response example or examples manually. Note that using multiple examples require Swagger UI 3.23.0+ or Swagger Editor 3.6.31+.

How do I use swagger with a status code?

A swagger:route can specify a response name for a status code and then the matching response will be used for that operation in the swagger definition. Syntax: swagger:response [?response name] Properties: Annotation

Does Swagger not like the “required” attribute?

But it appears that swagger does not like the "required" attribute and will show the following error message: When I look at an example from swagger, they have the following layout where there are two different response definitions instead of one.

How does Swagger work with other developers?

It works great out of the box to show other developers the basics of your resources. But the standard responses leave something to be desired. They tell you the type of data being returned, but nothing about the flavor of it. For example, let’s say your resource returns an address. Standard Swagger will show the user this:


1 Answers

You're getting the error in the model, because that's not the way to define required properties.

The correct form would be:

    "my_response_object": {         "type": "object",         "required": [ "result" ],         "properties": {             "result": {                 "type": "string",                 "description": "value of 'success' or 'error', indicated whether was successful"             },             "message": {                 "type": "string",                 "description": "an error message if there was an issue"             },             "filename": {                 "type": "string",                 "description": "the filename to return if the request was successful"             }         }     } 

Anything not in the required property is assumed to be optional. Keep in mind that this implies that it's possible to get both message and filename.

You can then use this model for your 200 response.

However - when it comes to REST API design, this breaks one of the more common standards. The status codes, taken from the HTTP protocol are meant to convey the outcome of the operation. 2XX are used for successful responses, 4XX are for errors due to bad user input, 5XX are for problems on the server side (3XX are for redirects). What you're doing here, is tell the client - the operation was successful, but in fact, it can be an error.

If you can still modify the API, I'd highly recommend making that distinction using the status codes, even using the fine tuned distinctions such as 200 for a successful GET operation, 201 for successful POST (or creation) operation and so on, based on the definitions here - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.

like image 61
Ron Avatar answered Sep 29 '22 19:09

Ron