Configuring editable properties

When a configuration is generated automatically (as for DAM services), any property that can be edited by the structure or included by tag is considered to be modifiable.

For reasons of upward compatibility and consistency with legacy services, any property that can be modified must be indicated in the data when it is created (POST) or modified (PUT).

Manage the mandatory nature of a property

Tag-based management

The function of tags configuring whether or not a field is mandatory is based on the following rules:

  • a structure tag is used to indicate the default behaviour of all the structure's fields

    • the rest_api_not_required tag indicates that fields are optional for creation and modification

    • the rest_api_required tag indicates that fields are mandatory for creation and modification

  • a tag can be placed on a field to override the default behaviour for that field

    • the rest_api_required tag indicates that this field is mandatory for creation and modification

      • the rest_api_create_required tag indicates that this field is mandatory for creation

      • the rest_api_update_required tag indicates that this field is mandatory in modification mode

    • the rest_api_not_required tag indicates that this field is optional for creation and modification

      • the rest_api_create_not_required tag indicates that this field is optional for creation

      • the rest_api_update_not_required tag indicates that this field is optional for modification.

  • on the same field, a mandatory tag is always considered to have priority over an optional tag

It is not possible to have different tagging behaviour for a structure, or its fields, for two different ranges of services (for example, the behaviour is the same for assets in a DAM service and a DATA service).

Until it's possible to do this using tags, the only solution is to configure it explicitly using JSON. You could, For example, use an automatic configuration generated with auto=true, change auto to false, and modify the resulting configuration.

Description of the rule application algorithm

The rule applied to each editable field is :

  1. if the field has the rest_api_required tag: it is mandatory for creation & modification

  2. otherwise

 

  1. if the field has the rest_api_create_required tag, field is mandatory for creation

  2. otherwise if the field has the tag rest_api_create_not_required, field is optional for creation

  3. otherwise if the field has the rest_api_not_required tag, field is mandatory for creation (at least)

  4. otherwise, if the structure has either the rest_api_create_not_required tag or the rest_api_not_required tag, field is optional for creation

 

  1. if the field has the rest_api_update_required tag, field is mandatory for modification

  2. otherwise if the field has the tag rest_api_update_not_required, field is optinal for modification

  3. otherwise, if the field has the rest_api_not_required tag, field is optinal for modification

  4. otherwise, if the structure has either the rest_api_update_not_required tag or the rest_api_not_required tag, the field is optional for modification

Configurations in JSON

Configurations in JSON always override configurations by tag, as soon as they are created.

The auto property is used to manage fields :

  • if auto is true

    • the configuration fields are determined by tags in the same way as for automatic configuration

    • if a field is explicitly configured in the JSON, its configuration replaces any configuration generated by tag. The properties that can be used to manage the mandatory or non-mandatory character are:

      • requiredcreate to true to indicate that the field is mandatory, or false to indicate that it is optional, in creation (default value: true)

      • requiredupdate to true to indicate that the field is mandatory, or false to indicate that it is optional, in modification (default value: true)

    • it is not possible to specify a default behaviour for all fields

  • if auto is false
    The configuration of all fields must be explicit in the JSON.