Skip to content
This repository has been archived by the owner on Feb 17, 2024. It is now read-only.

Discriminator expected behavior question #717

Open
jam01 opened this issue Aug 22, 2019 · 4 comments
Open

Discriminator expected behavior question #717

jam01 opened this issue Aug 22, 2019 · 4 comments

Comments

@jam01
Copy link

jam01 commented Aug 22, 2019

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!

@jstoiko
Copy link
Contributor

jstoiko commented Jul 24, 2020

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.

@jam01
Copy link
Author

jam01 commented Jul 24, 2020

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
Copy link
Author

jam01 commented Jul 15, 2021

@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?

@jstoiko
Copy link
Contributor

jstoiko commented Jul 16, 2021

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

2 participants