|
| 1 | +# Modeling collection subsets |
| 2 | + |
| 3 | +Microsoft Graph API Design Pattern |
| 4 | + |
| 5 | +*The modeling collection subsets pattern is the modeling state associated to a collection that may include all instances, an included subset, an excluded subset, no instances, or any combinations of the preceding items.* |
| 6 | + |
| 7 | +## Problem |
| 8 | + |
| 9 | +A common pattern is to apply a policy or state to a collection of resources. With this, there also comes the question of how to model cases where we want to apply to `all` or `none` without having to special case these values within the collection set or introduce cross-property dependencies. Likewise, we'd like to model it in a way where it is easy to understand and interpret usage from just looking at the schema. |
| 10 | + |
| 11 | +An example is where you have a policy that you need to be able to apply to users in an organization. You might want to support the default **None**, enablement for **All**, or enablement for **Select** users where you only grant it to a few users. |
| 12 | + |
| 13 | +Existing patterns for this either have special-cased `strings` or have tightly coupled dependencies between two independent properties. Neither is intuitive, both require reading documentation, and neither can be inferred from the schema or within client libraries. |
| 14 | + |
| 15 | +## Solution |
| 16 | + |
| 17 | +Have an abstract base class where all `variants` of the subset are derived types from the base subset. For more information, see the [general subtyping guidance](./subtypes.md). |
| 18 | + |
| 19 | +The abstract base class should also hold an enum for all possible variants. The purpose of including this is to allow for easier ways to do query and filter operations on variants like `all` and `none` without relying on `isof` functions. |
| 20 | + |
| 21 | +**Base type** |
| 22 | + |
| 23 | +```xml |
| 24 | + <ComplexType Name="membership" IsAbstract="true"> |
| 25 | + <Property Name="membershipKind" Type="graph.membershipKind"/> |
| 26 | + </ComplexType> |
| 27 | + |
| 28 | + <Enum Name="membershipKind"> |
| 29 | + <Member Name="all"/> |
| 30 | + <Member Name="enumerated"/> |
| 31 | + <Member Name="none"/> |
| 32 | + <Member Name="unknownFutureValue"/> |
| 33 | + </Enum> |
| 34 | +``` |
| 35 | + |
| 36 | +**Derived types** |
| 37 | + |
| 38 | +```xml |
| 39 | + <ComplexType Name="noMembership" BaseType="graph.membership"/> |
| 40 | + |
| 41 | + <ComplexType Name="allMembership" BaseType="graph.membership"/> |
| 42 | + |
| 43 | + <ComplexType Name="enumeratedMembership" BaseType = "graph.membership"> |
| 44 | + <Property Name="members" Type="Collection(Edm.String)"/> |
| 45 | + </ComplexType> |
| 46 | + |
| 47 | + <ComplexType Name="excludedMembership" BaseType="graph.membership"> |
| 48 | + <Property Name="members" Type="Collection(Edm.String)"/> |
| 49 | + </ComplexType> |
| 50 | +``` |
| 51 | + |
| 52 | +Be aware that the name values and types in the preceding examples are just examples and can be replaced with your scenario equivalent values. For example, type names don't really need to be `memberships`. The collection doesn't have to be a collection at all; it can be singular and doesn't have to be a string. |
| 53 | + |
| 54 | +These pattern type names should satisfy the following naming conventions: |
| 55 | + |
| 56 | +- The base type name should have the suffix `Base`, and the enumeration type name should have the suffix `Kind`. |
| 57 | +- Derived child types should have names with enumeration values as the prefixes; for example, if the enumeration member value is `value1`, then the derived type name is `value1<type>`. |
| 58 | + |
| 59 | +```xml |
| 60 | + <ComplexType Name="<type>Base" IsAbstract="true"> |
| 61 | + <Property Name="<type>Kind" Type="graph.<type>Kind"/> |
| 62 | + </ComplexType> |
| 63 | + |
| 64 | + <Enum Name="<type>Kind"> |
| 65 | + <Member Name="<value1>"/> |
| 66 | + <Member Name="<value2>"/> |
| 67 | + <Member Name="unknownFutureValue"/> |
| 68 | + </Enum> |
| 69 | + |
| 70 | + <ComplexType Name="value1<type>" BaseType="graph.<type>Base"/> |
| 71 | + |
| 72 | + <ComplexType Name="value2<type>" BaseType="graph.<type>Base"> |
| 73 | + <Property Name="<property-name>" Type="<property-type>"/> |
| 74 | + </ComplexType> |
| 75 | +``` |
| 76 | + |
| 77 | +## When to use this pattern |
| 78 | + |
| 79 | +Use this pattern when supporting two or more collection states of the following, where at least one of the states is a subset variant: |
| 80 | + |
| 81 | +- All targets |
| 82 | +- No targets |
| 83 | +- Subset of targets to be included |
| 84 | +- Subset of targets to be excluded |
| 85 | + |
| 86 | +If you only ever need to support two states—All or None—without using any subsets, it would be better to use a Boolean to toggle on and off. |
| 87 | + |
| 88 | +## Issues and considerations |
| 89 | + |
| 90 | +Given that we are using an overarching subtype model, subtyping model limitations apply here as well; for more details, see the [subtyping documentation](./subtypes.md). |
| 91 | + |
| 92 | +## Example |
| 93 | + |
| 94 | +```http |
| 95 | +GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/ |
| 96 | +``` |
| 97 | + |
| 98 | +_Note: Unrelated properties on entities are omitted for easier readability._ |
| 99 | + |
| 100 | +```json |
| 101 | +{ |
| 102 | + "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#conditionalAccessPolicy", |
| 103 | + "values": [ |
| 104 | + { |
| 105 | + "id": "66d36273-fe4c-d478-dc22-e0179d856ce7", |
| 106 | + "conditions": { |
| 107 | + "users": { |
| 108 | + "includeGuestsOrExternalUsers": { |
| 109 | + "externalTenants": { |
| 110 | + "@odata.type":"microsoft.graph.conditionalAccessAllExternalTenants", |
| 111 | + "membershipKind": "all" |
| 112 | + } |
| 113 | + } |
| 114 | + } |
| 115 | + } |
| 116 | + }, |
| 117 | + { |
| 118 | + "id": "99d212f4-d94e-cde1-8e3c-208d78238277", |
| 119 | + "conditions": { |
| 120 | + "users": { |
| 121 | + "includeGuestsOrExternalUsers": { |
| 122 | + "externalTenants": { |
| 123 | + "@odata.type":"microsoft.graph.conditionalAccessEnumeratedExternalTenants", |
| 124 | + "membershipKind": "enumerated", |
| 125 | + "members": ["bd005e2a-876d-4bf0-92a1-ae9ff4276d54"] |
| 126 | + } |
| 127 | + } |
| 128 | + } |
| 129 | + } |
| 130 | + } |
| 131 | + ] |
| 132 | +} |
| 133 | +``` |
| 134 | + |
| 135 | +```http |
| 136 | +POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/ |
| 137 | +``` |
| 138 | + |
| 139 | +_Note: Unrelated properties on entities are omitted for easier readability._ |
| 140 | + |
| 141 | +```json |
| 142 | +{ |
| 143 | + "id": "66d36273-fe4c-d478-dc22-e0179d856ce7", |
| 144 | + "conditions": { |
| 145 | + "users": { |
| 146 | + "includeGuestsOrExternalUsers": { |
| 147 | + "externalTenants": { |
| 148 | + "@odata.type":"microsoft.graph.conditionalAccessAllExternalTenants" |
| 149 | + } |
| 150 | + } |
| 151 | + } |
| 152 | + } |
| 153 | +} |
| 154 | +``` |
| 155 | + |
| 156 | +or |
| 157 | + |
| 158 | +```http |
| 159 | +POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/ |
| 160 | +``` |
| 161 | + |
| 162 | +_Note: Unrelated properties on entities are omitted for easier readability._ |
| 163 | + |
| 164 | +```json |
| 165 | +{ |
| 166 | + "id": "66d36273-fe4c-d478-dc22-e0179d856ce7", |
| 167 | + "conditions": { |
| 168 | + "users": { |
| 169 | + "includeGuestsOrExternalUsers": { |
| 170 | + "externalTenants": { |
| 171 | + "@odata.type":"microsoft.graph.conditionalAccessEnumeratedExternalTenants", |
| 172 | + "members": ["bd005e2a-876d-4bf0-92a1-ae9ff4276d54"] |
| 173 | + } |
| 174 | + } |
| 175 | + } |
| 176 | + } |
| 177 | +} |
| 178 | +``` |
0 commit comments