raml-spec icon indicating copy to clipboard operation
raml-spec copied to clipboard

Discriminator expected behavior question

Open jam01 opened this issue 4 years ago • 4 comments

Consider the following RAML

types:
  event:
    type: object
    discriminator: eventType
    properties:
      eventType: string

  fooEvent:
    type: event
    discriminatorValue: foo
    properties:
      bar: string

/resource:
   post:
     body:
       application/json:
         type: fooEvent

Expected behavior /resource should accept a value such as: {"eventType":"foo", "bar":"val"}

and reject a values such as: {"eventType":"not-foo", "not-bar":"val"} {"not":"acceptable"} {}

Is that correct?

I'm trying to understand exactly what can be expected of a data type validation library. I opened an issue with raml-java-parser and would like to find out if maybe I misunderstood what should be valid and invalid.

Thanks!

jam01 avatar Aug 22 '19 19:08 jam01

Correct. To be clear, the reason those values would be rejected in that case is because both eventType and bar are required properties, for example {"eventType":"not-foo", "bar":"val", "not-bar":"val"} would be valid. In order to disallow any other properties, you would have to set additionalProperties to false on your fooEvent type.

jstoiko avatar Jul 24 '20 16:07 jstoiko

Thanks @jstoiko :) It's been a long while since I opened this, but I think you confirmed a bug since {} is incorrectly accepted while it doesn't have the required eventType field.

Furthermore why would "not-foo" be accepted if there's no discriminator that matches that value?

To be clear that was the behavior when I opened this ticket about a year ago now. It may no longer be the case.

jam01 avatar Jul 24 '20 16:07 jam01

@jstoiko sorry to summon you back to this, but I'm reconsidering using RAML vs OpenAPI for some use cases (because I prefer RAML's data type system) but this specific question I'm still not clear on.

Why should "not-foo" be accepted if there's no discriminator that matches that value?

jam01 avatar Jul 15 '21 00:07 jam01

Can you attempt to parse and validate this using the latest version of AMF[1]? This is our reference parser now, the one you used back when you filed this issue has been deprecated.

[1] https://github.com/aml-org/amf

jstoiko avatar Jul 16 '21 22:07 jstoiko