Validation and defaults
The validation logic as well as the mechanisms for setting defaults are not strictly implemented in the business layer. Instead, a lot of additional validations and default value selections are done directly in the front-end part. Because the REST API implementation uses the business layer to create and update objects, most of these additional validation rules are bypassed when using the REST API, and defaults might not be applied. As a consequence, it can happen that invalid objects (e.g., with unset mandatory attributes) are created via REST, even though the same invalid object could not be created when using the front end.
Furthermore, the business layer provides multiple ways for creating some of the business objects. It can therefore happen that the way an object is created is different between REST and UI, which can also lead to invalid object attributes, namely if one of the construction options includes some attribute translation, whereas another option does not.
In some situations it is enough to load an object in the front end, adjust some attribute if needed, and save it again (e.g., to get defaults applied). If this is not enough, and if only very few objects are affected, it might be easiest to re-create these objects using the UI.
We strongly recommend you work with FULL updates only (see the chapter: Updating an existing resource). To modify, get the existing object first, adjust values on it and send this full object for doing the update. When creating a new object, get a similar existing one first, and use this response as a "template", so you do not overlook mandatory properties.