swagger-api / swagger-api/swagger-codegen-generators

[ALL] Form params - individual or as container?

Open
#315 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Mustache
Stars
299
Forks
439
PR merge metrics
No merged PRs in 30d

Description

While writing my own code generator I noticed something weird: codegen would generate models called Body, Body1, ... that the generated code didn't use.

After some digging I found out that this is a result of the change of how form parameters are handled in OAS2 (Swagger) vs. OAS3 (OpenAPI),

In OAS2 form parameters were defined like this:

parameters:
  - in: formData
    name: name
    type: string
    description: A person's name.
  - in: formData
    name: fav_number
    type: number
    description: A person's favorite number.

The "natural" form for the generated api methods here is to have individual parameters (name, fav_number).

In OAS3 the form has changed to this:

requestBody:
  content:
    multipart/form-data:
      schema:
        type: object
        properties:
          additionalMetadata:
            description: Additional data to pass to server
            type: string
          file:
            description: file to upload
            type: string
            format: binary

The "natural" form for this would be to pass all parameters as an object (as opposed to individual parameters).

In fact, if the content type is switched from multipart/form-data to application/json, all/most/some code generators will switch from individual parameters to container data types.

The problem with the redundant files I mentioned earlier stems from a design decision in the swagger parser: inline schemas are automatically "externalized", i.e. they're moved to the global components/schema section and replaced with a $ref. So, the example above basically becomes:

requestBody:
  content:
    multipart/form-data:
      schema:
        $ref: '#/components/schemas/body'

components:
  schemas:
    body:
      type: object
      properties:
        additionalMetadata:
          description: Additional data to pass to server
          type: string
        file:
          description: file to upload
          type: string
          format: binary

So, the code generators would see a model called body and thus generate a file for it - while the operations would use the formParams collection and create individual parameters.

The question now is: Which way will be the future?

The current implementation points to "container models" but this would be breaking change for existing api users. There are also two todos in the code that may suggest there is some plan for this. Unfortunately, they don't have an issue number so I'm not sure where their progress is tracked.

On the other hand we could stay with individual parameters but would then require a way to figure out whether a model file should be generated or not. (I'm currently trying this way but it's rather difficult because you need to find all schema usages in an OpenAPI instance - and there seems to be no straight forward way of doing this.)

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 with DefaultCodegenConfig.java, especially the formParams handling and its two TODOs, then review InlineModelResolver.java to understand why inline request schemas become generated models. Compare the OAS2 and OAS3 examples and existing generator behavior; done requires an agreed direction for individual form parameters versus container models, with the redundant-model behavior addressed consistently.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, openapi
Domain
devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.