Forum Discussion

dunkc's avatar
dunkc
Occasional Contributor
8 years ago
Solved

Can I mix parameter types in a Swagger document

I've an API definition (https://app.swaggerhub.com/api/dunkc/Payment/1.0) which has a single path to post the resource defined in the message body but also allows a query parameter to be passed. This seems sensible and 'legal' according to the specification. However, I'm getting a syntax error on my parameters definition stating

 

Swagger Error

The parameters needed to send a valid API call

 

and the error message "Expected type array but found type object"

 

I can't see an issue with the parameters definition (below), but wanted to check it was valid. It could also be an issue with the data definition the schema is referencing but even if I remove the whole body parameter referencing the schema I have the same error

 

parameters:
        paymentrequest:
          name: paymentrequest
          in: body
          description: a request to make a transfer of money
          required: true
          schema:
            $ref: "#/definitions/Payment_Request_Full"
        brand:
          name: brand
          in: query
          description: blah, blah
          required: true
          type: string

  • Hi there, glad to see you've solved the issue.

     

    There are two places parameters can be declared inside an API spec.

    The first is at the top level, being referred to as the Parameters Definitions Object - http://swagger.io/specification/#parameters-definitions-object-103. There, you can define parameters that can be reused in your spec. For that reason, the structure is a map of names that you give to those parameters, and their actual structure.

     

    The second place is under the operations themselves. In that case, `parameters` is an array of parameters, that can either be defined directly there or referenced to the parameters defined above for reuse.

     

    The structure of `parameters` differs (object vs array), which is why you saw a different example than what you actually needed.

3 Replies

  • dunkc's avatar
    dunkc
    Occasional Contributor

    After looking at this for sometime I've actually solved this by changing the syntax to

     

    parameters:
            - name: paymentrequest
              in: body
              description: a request to make a transfer of money
              required: true
              schema:
                $ref: "#/definitions/Payment_Request_Full"
            - name: brand
              in: query
              description: blah, blah
              required: true
              type: string

     

    This doesn't seem in keeping with the Open API specification and the examples shown in there for multiple parameters in YAML, see below

     

    skipParam:
      name: skip
      in: query
      description: number of items to skip
      required: true
      type: integer
      format: int32
    limitParam:
      name: limit
      in: query
      description: max records to return
      required: true
      type: integer
      format: int32

     

    • RonRatovsky's avatar
      RonRatovsky
      Moderator

      Hi there, glad to see you've solved the issue.

       

      There are two places parameters can be declared inside an API spec.

      The first is at the top level, being referred to as the Parameters Definitions Object - http://swagger.io/specification/#parameters-definitions-object-103. There, you can define parameters that can be reused in your spec. For that reason, the structure is a map of names that you give to those parameters, and their actual structure.

       

      The second place is under the operations themselves. In that case, `parameters` is an array of parameters, that can either be defined directly there or referenced to the parameters defined above for reuse.

       

      The structure of `parameters` differs (object vs array), which is why you saw a different example than what you actually needed.

      • dunkc's avatar
        dunkc
        Occasional Contributor

        That makes sense, thanks.

         

        I'm not sure this is that clear in the specification though :smileyhappy: