yahehe / Nancy.Swagger

Nancy plugin for generated API documentation in Swagger format.
MIT License
133 stars 60 forks source link

Validation failed #107

Open sergiychernov opened 7 years ago

sergiychernov commented 7 years ago

@yahehe, @jnallard,

Found few strange things. swagger.json produced by Nancy.Swagger is invalid. This is validator i used http://bigstickcarpet.com/swagger-parser/www/index.html


{  
   "swagger":"2.0",
   "info":{  
      "title":"some api",
      "description":"Our awesome api service",
      "contact":{  
         "name":"Bla",
         "email":"bla@gm.com"
      },
      "version":"0.0.1"
   },
   "paths":{  
      "/api/v1/data":{  
         "post":{  
            "tags":[  
               "some tag"
            ],
            "summary":"summary",
            "description":"description",
            "operationId":"id",
            "parameters":[  
               {  
                  "name":"Data",
                  "in":"formData",
                  "description":"Object containing data",
                  "type":"Data"
               }
            ],
            "responses":{  
               "DataResponse":{  
                  "schema":{  
                     "$ref":"#/definitions/DataResponse"
                  }
               }
            },
            "security":{ 
                     "apiKey" :[]
            }
         },
         "parameters":[  

         ]
      }
   },
   "definitions":{  
      "Data":{  
         "properties":{  
            "password":{  
               "type":"string"
            },
            "username":{  
               "type":"string"
            }
         },
         "type":"object",
         "$ref":"#/definitions/Data"
      },
      "DataResponse":{  
         "properties":{  
            "expiry":{  
               "type":"integer"
            },
            "token":{  
               "type":"string"
            }
         },
         "required":[  
            "expiry"
         ],
         "type":"object",
         "$ref":"#/definitions/DataResponse"
      }
   },
   "securityDefinitions":{  
      "Bearer":{  
         "type":"apiKey",
         "description":"Authentication with Bearer token",
         "name":"Authorization",
         "in":"header"
      }
   },
   "tags":[  
      {  
         "name":"some tag"
      }
   ]
}

There are some points:

What do you think about this?

Thanks.

sergiychernov commented 7 years ago

And this is swagger.json that passes validation


{  
   "swagger":"2.0",
   "info":{  
      "title":"some api",
      "description":"Our awesome api service",
      "contact":{  
         "name":"Bla",
         "email":"bla@gm.com"
      },
      "version":"0.0.1"
   },
   "paths":{  
      "/api/v1/data":{  
         "post":{  
            "tags":[  
               "some tag"
            ],
            "summary":"summary",
            "description":"description",
            "operationId":"id",
            "parameters":[  
               {  
                  "name":"Data",
                  "in":"body",
                  "description":"Object containing data",
                  "schema":{
                     "$ref":"#/definitions/Data"
                  }
               }
            ],
            "responses":{  
               "200":{  
                 "description":"",
                  "schema":{  
                     "$ref":"#/definitions/DataResponse"
                  }
               }
            },
            "security":[ 
                  {  
                     "apiKey" :[]
                  }
            ]
         },
         "parameters":[  

         ]
      }
   },
   "definitions":{  
      "Data":{  
         "properties":{  
            "password":{  
               "type":"string"
            },
            "username":{  
               "type":"string"
            }
         },
         "type":"object",
         "$ref":"#/definitions/Data"
      },
      "DataResponse":{  
         "properties":{  
            "expiry":{  
               "type":"integer"
            },
            "token":{  
               "type":"string"
            }
         },
         "required":[  
            "expiry"
         ],
         "type":"object",
         "$ref":"#/definitions/DataResponse"
      }
   },
   "securityDefinitions":{  
      "Bearer":{  
         "type":"apiKey",
         "description":"Authentication with Bearer token",
         "name":"Authorization",
         "in":"header"
      }
   },
   "tags":[  
      {  
         "name":"some tag"
      }
   ]
}
jnallard commented 7 years ago

I don't remember if you're using Annotations or the default package. Which are you using?

security should be array of objects where object key is auth type and its value - array of strings

The security on the route is probably actually broken, so we should look into that. (When I was working on fixing the security definitions, I forgot to actually apply them to the routes when checking the validator; I only validated the actual definition.)

response keys should be status codes only

I don't know how you got the response to look like that, but the samples are formed correctly. Show me an example route code that generates this? Or verify that your responses look similar to the sample code. But we can try to pinpoint this to disallow it from happening, but it is possible to get it to format correctly as is.

IN key in parameters should be 'body' not 'formData'

'formData' is a valid IN value. And the samples use both 'body' and 'form'. This is probably a matter of things being misconfigured. Though it could also be something that was previously overlooked. Can I see a sample of the code that's generating this issue?

in same parameter type is not allowed, but schema should be present

Parameter.type is allowed because the code thinks you're specifying a form parameter, not a body parameter. If the code actually creates it as a body parameter, the "$ref" value will be there (Though type is there too and should probably be cleaned up, but this didn't throw any errors in the validator for me)