thim81 / openapi-format

Format an OpenAPI document by ordering, formatting and filtering fields.
MIT License
77 stars 14 forks source link

sort - order request parameters by name #82

Open ed-randall-blk opened 10 months ago

ed-randall-blk commented 10 months ago

I couldn't figure out how to do this. I need the get, post etc. request parameters to be ordered by the value of the name field. The parameter fields themselves are ordered consistently according to the config but I'd like the the parameter ordering itself to be alphabetical.

    "/api/products": {
      "get": {
        "summary": "Get the list of existing products.",
        "parameters": [
          {
            "name": "offset",    _this should be the second one_
            "in": "query",
            "description": "The offset to apply to the paginated query.",
            "required": false,
            "default": 0,
            "format": "int32",
            "minimum": 0,
            "type": "integer"
          },
          {
            "name": "limit",        _l comes before o, this should be the first one_
            "in": "query",
            "description": "The limit to apply to the paginated query.",
            "required": false,
            "default": null,
            "format": "int32",
            "maximum": 100,
            "minimum": 0,
            "type": "integer",
            "x-nullable": true
          }
        ],
thim81 commented 10 months ago

hi @ed-randall-blk

Usually the parameters are used as $ref to be re-used, so this is an interesting case, I'll have to investigate the behaviour of inline parameters.

thim81 commented 8 months ago

hi @ed-randall-blk

I have a PR ready for this, but I wonder if people expect this to be sorted or rather want to keep it in the order that they defined it? Since it might be linked to a priority related to the business rules?

Example before:

  '/pet/{petId}/uploadImage':
    post:
      operationId: uploadFile
      summary: uploads an image
      description: ''
      parameters:
        - required: true
          schema:
            type: integer
            format: int64
          name: petId
          in: path
          description: ID of pet to update
        - required: false
          schema:
            type: string
          name: additionalMetadata
          in: query
          description: Additional Metadata
  /user/login:
    get:
      parameters:
        - required: false
          schema:
            type: string
          name: username
          in: query
          description: The user name for login
        - required: false
          schema:
            type: string
          name: password
          in: query
          description: The password for login in clear text

Example after:

  '/pet/{petId}/uploadImage':
    post:
      operationId: uploadFile
      summary: uploads an image
      description: ''
      parameters:
        - required: false
          schema:
            type: string
          name: additionalMetadata
          in: query
          description: Additional Metadata
        - required: true
          schema:
            type: integer
            format: int64
          name: petId
          in: path
          description: ID of pet to update
  /user/login:
    get:
      parameters:
        - required: false
          schema:
            type: string
          name: password
          in: query
          description: The password for login in clear text
        - required: false
          schema:
            type: string
          name: username
          in: query
          description: The user name for login
thim81 commented 6 months ago

hi @ed-randall-blk

Did you had some time to review the PR and the question above?

edrandall commented 6 months ago

Hi - thanks!

Ours swagger.json is generated from either golang protoc or Python ApiSpec hence why I think we don't see the $ref. But the generating is not always consistently ordered - hence we want this tool so that the diff shows true diffs without any noise.

Really our main use-case then is a cross-check reviewing the changes vs the previous version before installing the swagger.json into Apigee. No business rule ordering as such. But in any case this sort would be the up to the end-user right, depending on whether they choose to configure it this way, or not. No-one is forced into anything they don't want.