Open API Spec File fails parsing about fastapi-httpbin HOT 4 CLOSED

I have found that I can parse your spec file with editor.swagger.io and if I remove the request body and adjust the QR code sizing parameters to booleans everything validates perfectly. I'm going to mark this closed and if the issue comes up with anyone else this can be a reference issue.

from fastapi-httpbin.

Some additional information that may be relevant:

In section 4.3.5 DELETE from RFC 7231 (https://www.rfc-editor.org/rfc/rfc7231#page-29)

   A payload within a DELETE request message has no defined semantics;
   sending a payload body on a DELETE request might cause some existing
   implementations to reject the request.

from fastapi-httpbin.

Good catch, I wasn't aware validators for OpenAPI existed!

I did know that having a payload for DELETE isn't supported--I opted to add it in specifically so that people using the Swagger interface at https://httpbin.dmuth.org/ could set and delete cookies while playing around in their web browser. In fact, I'll go a little further and say that I think the functionality is helpful for people who are trying to understand how cookies work, and want to explore the behavior in their web browser.

That said, I'm not sure what the "best" way to approach this is. I can think of a few ideas off the top of my head:

• Remove the payload for DELETE /cookies. I'd prefer not to do this for the reasons above.
• Tweak the code that writes to /openapi.json to not list that. That would require me to hack on/fork FastAPI (not a great idea), and I would now have something that isn't documented. (also not a great idea)
• Come up with another way to delete cookies. (Maybe path data on the URL? Would prefer that I can also make this work in the Swagger page)

I'm open to any suggestions, maybe there's a better idea that I haven't considered yet?

Best,

-- Doug

from fastapi-httpbin.

I honestly wasn't aware of the differences in validator versions either (and as of today how many different modules/packages/libraries that validate) until I really dug into trying to put this behind an API security gateway that can validate based on the swagger file's contents.

In my case, I fixed it by removing the response body stanza from the delete section (suboptimal but I'll roll with it until I can't), and switching minimumExclusive to booleans while specifying a 'minimum: 0.0' key:value (with no idea what each value does) and it passes version 0 validation.

I am unsure of the scope of this issue for how it will affect the intended users of this application. My case is to use it in a very selective security use case rather than for pure development work, although I will be interacting with it in the course of my testing. Perhaps the best path is to note that this validation disparity can arise if the OAS file doesn't conform to https://json-schema.org/specification but rather draft versions with extended functionality. If no one else is having this issue I can accept a PEBCAK and we'll chock this up to a curiosity?

from fastapi-httpbin.