Patterns for modeling your resource types

Use the following patterns to model the data structures of your resource types using the Resource Provider Schema.

How to specify a property as dependent on another

Use the dependencies element to specify if a property is required in order for another property to be specified. In the following example, if the user specifies a value for the ResponseCode property, they must also specify a value for ResponsePagePath, and vice versa. (Note that, as a best practice, this is also called out in the description of each property.)

"properties": {
"CustomErrorResponse": {
    "additionalProperties": false,
    "dependencies": {
        "ResponseCode": [
            "ResponsePagePath"
        ],
        "ResponsePagePath": [
            "ResponseCode"
        ]
    },
    "properties": {
        "ResponseCode": {
            "description": "The HTTP status code that you want CloudFront to return to the viewer along with the custom error page. If you specify a value for ResponseCode, you must also specify a value for ResponsePagePath.",
            "type": "integer"
        },
        "ResponsePagePath": {
            "description": "The path to the custom error page that you want CloudFront to return to a viewer when your origin returns the HTTP status code specified by ErrorCode. If you specify a value for ResponsePagePath, you must also specify a value for ResponseCode.",
            "type": "string"
        }
        . . . 
    },
    "type": "object" 
},
},
. . . 

How to define nested properties

It's considered a best practice is to use the definitions section to define schema elements that may be used at multiple points in your resource type schema. You can then use a JSON pointer to reference that element at the appropriate places in your resource type schema.

For example, define the reused element in the definitions section:

"definitions": {
    "AccountId": {
        "pattern": "^[0-9]{12}$",
        "type": "string"
    },
    . . . 
},
. . . 

And then reference that definition where appropriate:

"AwsAccountNumber": {
    "description": "An AWS account that is included in the TrustedSigners complex type for this distribution.",
    "$ref": "#/definitions/AccountId"
},
    . . . 

Advanced: How to encapsulate complex logic

Use the allOf, oneOf, or anyOf elements to encapsulate complex logic in your resource type schema.

In the example below, if whitelist is specified for the Forward property in your resource, then the WhitelistedNames property must also be specified.

"properties": {
"Cookies": {
    "oneOf": [
        {
            "additionalProperties": false,
            "properties": {
               "Forward": {
                    "description": "Specifies which cookies to forward to the origin for this cache behavior.",
                    "enum": [
                        "all",
                        "none"
                    ],
                    "type": "string"
                }
            },
            "required": [
                "Forward"
                ]
        },
     ],
        {
            "additionalProperties": false,
            "properties": {
                "Forward": {
                    "description": "Specifies which cookies to forward to the origin for this cache behavior.",
                    "enum": [
                        "whitelist"
                    ],
                    "type": "string"
                },
                "WhitelistedNames": {
                    "description": "Required if you specify whitelist for the value of Forward.",
                    "items": {
                       "type": "string"
                    },
                    "minItems": 1,
                    "type": "array"
                }
            },
            "required": [
                "Forward",
                "WhitelistedNames"
            ]
        },
    "type": "object"
    }
}
. . .