{"__v":1,"_id":"56c51f1cf7c4da0d00614b02","category":{"__v":13,"_id":"56a96d338791090d00113bab","pages":["56a96d492bb3910d000ee931","56c3cec2106c12170020db96","56c51da4ba4a540d0091b9b7","56c51dc3ba4a540d0091b9b9","56c51eb916c7190d00ff7b19","56c51ec2d7b9ed19008d1752","56c51eec668eb01900719bcd","56c51effba4a540d0091b9bb","56c51f1cf7c4da0d00614b02","56c51f2a8dc1c51900abc142","56c51f367de3580d00bdaf2a","56c67b6270e7660d004a8985","56c67b7cfd00bb0d0016daad"],"project":"564e5930c3553e0d003e53d0","version":"564e5a9b1560880d008d30dc","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-01-28T01:21:55.716Z","from_sync":false,"order":1,"slug":"patterns","title":"REST API"},"parentDoc":null,"project":"564e5930c3553e0d003e53d0","user":"564e5788230d7c1700c9073e","version":{"__v":21,"_id":"564e5a9b1560880d008d30dc","project":"564e5930c3553e0d003e53d0","createdAt":"2015-11-19T23:26:19.166Z","releaseDate":"2015-11-19T23:26:19.166Z","categories":["564e5a9b1560880d008d30dd","566318e1f5ca460d00f41896","56631d08cd54d50d005015fa","56631d2a81ad7417006a202c","5668ba19fbd7680d009375f4","5668cb8b10bda80d00797ed9","5668cb9d10bda80d00797eda","56830d8a3f94e00d004e2a7a","56830d9072bb720d0091f594","56830d94cb4d190d0027698e","56830dc44aecbd0d00a464c5","569e90f3c9b43e0d00c4bab1","56a96d338791090d00113bab","56b12d8336d2580d00247877","56c36bf0a869d017002ea55b","56c36bf93d30210d00ea84bb","56c77749b935671700ff0304","56c7ab9e5652c217008e091a","56cb8bdad5c6241d00ef5e61","58aefce02470660f00b54539","58aefd0bebd7370f0078b954"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"Foundation","version_clean":"2.0.0","version":"2"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-02-18T01:32:12.668Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":9,"body":"All resources in the PagerDuty REST API have a single, canonical schema uniquely identified by the resource's `type`. Simply put, the same set of fields will always be present for a resource of a given `type`.\n\nEvery field within the schema adheres to a single [primitive type](doc:types).\n\nIn some cases, a resource may not contain a value for a field. The field will still be present in the resource and the value will be `null`. If the field can contain multiple values but the resource does not have any values for that field, the field will still be present and the value will be an empty array (`[]`). See [types](doc:types) for more information about field types.\n\nTo promote forward compatibility, clients should expect and ignore any extra fields in the schema that they do not recognize. This also enables the use of [generic schemas for specific types](#section-type-specificity).\n\n##### Type specificity\n\nWhile the value of a `type` field always provides the most specific information available about a resource's schema, there may be a more generic schema available that can also be used to understand the resource. More specific schemas are purely additive to the corresponding generic schema.\n\nFor instance, while there may be a schema corresponding to `cat_animal`, any `cat_animal` resource will also conform to the `animal` schema. A client concerned about `animal`s in general and not the specifics of `dog_animal` vs. `cat_animal` vs. `mouse_animal` can interpret every response from the `/animals` endpoint, or any `type` ending in `_animal` across the API as having a valid `animal` schema.\n\nSimilarly, *any* resource always conforms to a valid `reference` schema. If the client is only interested in displaying a list of resources by their [`summary`](doc:references#section--summary-), it does not need to know anything about the `type` of those resources as they can all be interpreted as valid `reference`s.","excerpt":"","slug":"resource-schemas","type":"basic","title":"Resource Schemas"}
All resources in the PagerDuty REST API have a single, canonical schema uniquely identified by the resource's `type`. Simply put, the same set of fields will always be present for a resource of a given `type`. Every field within the schema adheres to a single [primitive type](doc:types). In some cases, a resource may not contain a value for a field. The field will still be present in the resource and the value will be `null`. If the field can contain multiple values but the resource does not have any values for that field, the field will still be present and the value will be an empty array (`[]`). See [types](doc:types) for more information about field types. To promote forward compatibility, clients should expect and ignore any extra fields in the schema that they do not recognize. This also enables the use of [generic schemas for specific types](#section-type-specificity). ##### Type specificity While the value of a `type` field always provides the most specific information available about a resource's schema, there may be a more generic schema available that can also be used to understand the resource. More specific schemas are purely additive to the corresponding generic schema. For instance, while there may be a schema corresponding to `cat_animal`, any `cat_animal` resource will also conform to the `animal` schema. A client concerned about `animal`s in general and not the specifics of `dog_animal` vs. `cat_animal` vs. `mouse_animal` can interpret every response from the `/animals` endpoint, or any `type` ending in `_animal` across the API as having a valid `animal` schema. Similarly, *any* resource always conforms to a valid `reference` schema. If the client is only interested in displaying a list of resources by their [`summary`](doc:references#section--summary-), it does not need to know anything about the `type` of those resources as they can all be interpreted as valid `reference`s.