Is it possible specify "additionalProperties: false" on OpenAPI types?

[jamestelfer]

I can't see a way to do this currently either with the DSL or via metadata.

Is there an easy way to do this, or is there an example of a plugin that modifies the OpenAPI documents? (TBH, a pointer at the hook to plug into would be just as handy).

Thanks!

[raphael]

Hmm I thought that omitting this field would be equivalent to setting it to false. If that's not the case we could remove the omitempty tag on the struct field so it always generates even when false.

[jamestelfer]

Noodling around the specs ... Goa supports OpenAPI 3.03, whose specification states that:

additionalProperties - Value can be boolean or object. Inline or referenced schema MUST be of a Schema Object and not a standard JSON Schema. Consistent with JSON Schema, additionalProperties defaults to true.

So that would mean changing the schema definition as you suggest I think.

It leads to another question though: if the API spec suggests that additional properties are not allowed, should the server code reject requests that include additional properties instead of ignoring them? I'd say probably not (or at least opt in) as it would make it harder for services to evolve their APIs by adding additional capabilities.

I'm OK with a PR for modifying the spec generation, but I wouldn't really know where to start with changing the code generation for the second part.

[raphael]

I see yes we should remove the omitempty tag then - thanks for pointing this out. I guess I don't see how one would specify additional properties in the first place unless the type was a MapOf in which the value of additionalProperties should be true?

[jamestelfer]

If a request is created by a client in a different language, it could send a bunch of unsupported properties. Should the server actively reject such a request?

It's not valid according to the schema, so a strict interpretation would be "no it shouldn't". Practically though, it's often an advantage to accept such requests and ignore the additional data.

I'm happiest with leaving it as it is, just flagging it as a scenario to consider.

[jamestelfer]

I'll create an issue and a PR for the change above, thanks for the direction!

[raphael]

Yep, makes sense. Thank you for putting together a PR!