swagger-api / swagger-api/swagger-core

swagger validate should flag GET operations with body parameters as errors

Open
#4,348 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

backlog
Dominant language
Java
Stars
7.5k
Forks
2.3k
Avg merge
18h 1m
Merged PRs (30d)
10

Description

Running swagger validate against a spec that includes GET operations with parameters in the body does not produce any errors or warnings for any version of OpenAPI.

HTTP GET requests that have a body were only very recently added to the HTTP spec itself and are not allowed by OpenAPI prior to version 3.1. In the first place, specs which claim to be using the older version which contain these types of operations are not valid. In the second place even for users of OpenAPI 3.1, there are very good reasons to want to forbid these sorts of operations depending on what external HTTP clients are going to be accessing the API. So ideally I would want some option for swagger validate to enforce this as a standard even when validating a 3.1 spec.

The absence of this validation causes user confusion because the specs in question are also not generally compatible with most browsers, so people are opening issues like this one: #4327

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the swagger validate entry point and trace how request bodies and OpenAPI versions are validated, using the behavior described in #4327 as context. Done means GET operations with body parameters are rejected for OpenAPI versions before 3.1, with an option to enforce the restriction for 3.1 specifications.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
api
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.