hi @Boschy, I think you’re on the right path (pun intended).
In RAML 1.0, fields/properties are
required by default. so if you wanted to keep it as DRY as possible, you could have one single type referenced in both your GET response and POST request definitions, and have another type for your PUT request with either
required: false or
<field_name>? set on the properties you’d want to be optional.
As you may have read in the Specs,
a required property in the parent type cannot be changed to optional in the sub-type, but nothing prevents to do the opposite. So you could technically have a parent type with optional properties, use that type for PUT/PATCH, and have a sub-type inheriting from that parent type with
required: true set on all properties that were set optional in the parent type, and use that sub-type for both GET (response) and POST (request).
I would not personally use nor recommend the latter approach because I find it a bit odd to start from the “update” case, and I personally prefer the whitelist vs blacklist approach in most things I do. But if the Specs allow it, then it’s not necessarily “wrong”.
The former approach is how I would personally go about it unless I absolutely wanted to make sure that my GET response contain ALL fields (all required), in which case I would write three different types.
I hope this was helpful.