[REQ][Ruby] Add Strict Type Validation

[dbunn-calendly]

Is your feature request related to a problem? Please describe.

Currently the ruby generated library doesn't perform strict type validation on properties.
Given I have this schema:

Widget:
  type: object
  required: [name, owner]
  properties:
    name:
      type: string
    owner:
      type: object
      required: [id]
      properties:
        id:
          type: string

The generated Widget model will accept the following and not cause an error:

widget = Widget.new(name: 123, owner: true)

If I was then to call widget.valid?, it would return true even though the widget object does not adhere to the schema.

This can be problematic when integrating the library into other projects and you want to rely upon it for schema validation during testing. It is common when testing for external HTTP requests/responses to be mocked. This can result in a situation where incorrect data is mocked and passed to the library but tests pass because the schema wasn't strictly validated at any point.

Describe the solution you'd like

Update methods like initialize and valid? with strict type validation. For valid? this could be as simple as this:

return false unless @name.is_a?(String)
return false unless @owner.is_a?(Owner)
return false unless @owner.valid?

This additional validation could be disabled by default and only added when a generator specific config is set. Maybe strictTypeValidation=true? Putting this behind a config will help ensure we don't introduce any backward incompatible behavior.

Describe alternatives you've considered

Including json-schema as a dependence and replacing existing schema validation with calls to this library.

• Pros:
  • Allows us to leverage existing schema validation work in the ruby community
  • Simplifies generated code as it can delegate validation to json-schema
• Cons:
  • Adds an additional dependence to the generated library which is currently quite lean.
  • Validation may be slower than currently. (speculation)
  • This is most likely a negligible
  • Changes the paradigm for validation within the generated library
  • Potentially backward incompatible

Alternatively this solution or the purposed one could be implement in a new Ruby client generator. Maybe ruby-strict-types?

Additional context

None that I can think of at this time.

[wing328]

Maybe strictTypeValidation=true? Putting this behind a config will help ensure we don't introduce any backward incompatible behavior.

Sounds good to me. I wonder if you can file a PR for that to start with. Thank you.

[dbunn-calendly]

@wing328, I can work on a PR for this. Thanks