Does not support query array parameters

[Eugene Lim]

Currently, grape-swagger does not support query array parameters, setting them to formData by default:

https://github.com/ruby-grape/grape-swagger/blob/master/lib/grape-swagger/doc_methods/parse_params.rb#L87

        def document_array_param(value_type, definitions)
          if value_type[:documentation].present?
            param_type = value_type[:documentation][:param_type]
            doc_type = value_type[:documentation][:type]
            type = DataType.mapping(doc_type) if doc_type && !DataType.request_primitive?(doc_type)
            collection_format = value_type[:documentation][:collectionFormat]
          end

          param_type ||= value_type[:param_type]

          array_items = parse_array_item(
          array_items = parse_array_item(
            definitions,
            type,
            value_type
          )

          @parsed_param[:in] = param_type || 'formData'
          @parsed_param[:items] = array_items

This situations where as long as it is an array parameter, even if it occurs in a get request, by default the parameter's in is set to formData.

However, according to the OpenAPI v2 spec, Query parameters only support primitive types. You can have an array, but the items must be a primitive value type. Objects are not supported.

As such, in situations where there an array parameter's in/param_type is not explicitly defined and it occurs in a GET request and the array items type are non-object primitive value types, it should be set as query type.

[kamil-kudra]

I've come across the issue you mentioned regarding query parameters and arrays in the Swagger-Grape gem, and I'd like to share my thoughts on this.

It's important to note that this limitation, where query parameters only support primitive types and arrays must consist of primitive value types, can indeed be a bit restrictive in certain use cases. Not being able to use complex objects in query parameters or arrays within the request payload can be a limitation when working with more complex data structures.

I believe this limitation could potentially be challenging when dealing with more intricate data schemas and API designs, especially when it comes to representing nested or structured data.

It might be beneficial to explore whether this limitation can be addressed or if there's a workaround that allows for more flexibility in the use of complex data structures in both query parameters and request payloads.