Allow path param and request body to be passed at the same time

[jalyna]

Right now it is not possible in open api 3 to set a path param and a request body.

Not sure though if this is the right way but it worked for the spec we are using.

[ota42y]

The problem you pointed out is correct and this needs to be fixed.
However, this change greatly disrupts backward compatibility.

Currently, we are use 4 data (path, query, form and request body).
The problem occurs because we combine all of this into a one variable specified by params_key.
I think you can avoid them by using different keys
So we need add path_params_key, query_params_key, form_params_key, and request_params_key to set values.

[kurko]

@ota42y can you be more specific? Why would that break older versions?

I have an interest in this PR and would like to help move it forward.

[ota42y]

The committee support convert datetime string to datetime object.

If we don't use committee with this code (Ruby on Rails),
we'll get ArgumentError because params[:registered_at] is string and Time.now is Time class.
But the committee convert params[:registered_at] to DateTime, so this code is valid.

class UsersController < ApplicationController
    skip_before_action :verify_authenticity_token

    def create
        binding.pry
        registered_at = params[:registered_at]
        raise "error" unless registered_at < Time.now
        user = ["debug user1"] # do something

        head :ok
    end
end

When we use this feature on rails, we need this config to set converted value to ActionController::Parameters.

    schema_path = Rails.root.join("config/openapi.yaml").to_s
    config.middleware.use Committee::Middleware::RequestValidation, 
      schema_path: schema_path,
      params_key: 'action_dispatch.request.request_parameters'

But this change break this code because this code pass nested hast to ActionController::Parameters.

• old version
  • {"registerd_at": DateTime Object}
• this version
  • {"body": {"registered_at": DateTime Object}}

https://gist.github.com/ota42y/0870100c03444d39d78107a23de9f171

[hedselu]

Any update on this issue?

[makdad]

@ota42y I believe with 5.0 released, this issue is "fixable" in the sense that backward compatibility is less of an issue for the hash keys. Could you confirm? This is a pretty big issue for Open API Spec compatibility IMO.

I'd even be happy to jump in and help on the PR if necessary.