You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: graph/patterns/upsert.md
+15-10Lines changed: 15 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,11 +2,11 @@
2
2
3
3
Microsoft Graph API Design Pattern
4
4
5
-
*The `UPSERT` pattern is a non-destructive idempotent operation using a client-provided key, that ensures that system resources can be deployed in a reliable, repeatable, and controlled way, typically used in Infrastructure as Code (IaC) scenarios.*
5
+
*The `Upsert` pattern is a non-destructive idempotent operation using a client-provided key, that ensures that system resources can be deployed in a reliable, repeatable, and controlled way, typically used in Infrastructure as Code (IaC) scenarios.*
6
6
7
7
## Problem
8
8
9
-
Infrastructure as code (IaC) defines system resources and topologies in a descriptive manner that allows teams to manage those resources as they would code.
9
+
Infrastructure as code (IaC) defines system resources and topologies in a declarative manner that allows teams to manage those resources as they would code.
10
10
Practicing IaC helps teams deploy system resources in a reliable, repeatable, and controlled way.
11
11
IaC also helps automate deployment and reduces the risk of human error, especially for complex large environments.
12
12
Customers want to adopt IaC practices for many of the resources managed through Microsoft Graph.
@@ -19,20 +19,20 @@ Additionally, IaC code scripts or templates usually employ client-provided names
19
19
20
20
## Solution
21
21
22
-
The solution is to use an `UPSERT` pattern, to solve for the non-idempotent creation and client-provided naming problems.
22
+
The solution is to use an `Upsert` pattern, to solve for the non-idempotent creation and client-provided naming problems.
23
23
24
-
* For IaC scenarios, resources must use `UPSERT` semantics with an [alternate key](./alternate-key.md):
24
+
* For IaC scenarios, resources must use `Upsert` semantics with an [alternate key](./alternate-key.md):
25
25
* Use `PATCH` with a client-provided alternate key.
26
26
* For a non-existent resource (specified by the alternate key) the service must handle this as a "create". As part of creation, the service must still generate the primary key value.
27
27
* For an existing resource (specified by the alternate key) the service must handle this as an "update.
28
28
* Any new alternate key, used for IaC scenarios, should be called `uniqueName`, if there isn't already an existing property that could be used as an alternate key.
29
29
* NOTE: the service must also support `GET` using the alternate key pattern.
30
30
* For consistent CRUD Microsoft Graph behaviors, all resources, **including** resources used in IaC scenarios, should use `POST` and a service-generated primary key, per existing guidelines, and support `GET`, `PATCH` and `DELETE` using the primary key.
31
-
* If a service does not support `UPSERT`, then a `PATCH` call against a non-existent resource must result in an HTTP "409 conflict" error.
31
+
* If a service does not support `Upsert`, then a `PATCH` call against a non-existent resource must result in an HTTP "409 conflict" error.
32
32
33
-
This solution allows for existing resources that follow Microsoft Graph conventions for CRUD operations to add `UPSERT` without impacting existing apps or functionality.
33
+
This solution allows for existing resources that follow Microsoft Graph conventions for CRUD operations to add `Upsert` without impacting existing apps or functionality.
34
34
35
-
Ideally, all new entity types should support an `UPSERT` mechanism, especially if the resource is likely be used in IaC scenarios.
35
+
Ideally, all new entity types should support an `Upsert` mechanism, especially where they support control-plane APIs, or are used in admin style or IaC scenarios.
36
36
37
37
## When to use this pattern
38
38
@@ -42,10 +42,10 @@ This pattern should be adopted for resources that are managed through infrastruc
42
42
43
43
* The addition of this new pattern (with alternate key) does not represent a breaking change.
44
44
However, some API producers may have concerns about accidental usages of this new pattern unwittingly creating many new resources when the intent was an update.
45
-
As a result, API producers can use the `Prefer: idempotent` to require clients to opt-in to the UPSERT behavior.
45
+
As a result, API producers can use the `Prefer: idempotent` to require clients to opt-in to the Upsert behavior.
46
46
* The client-provided alternate key must be immutable after being set. If its value is null then it should be settable as a way to backfill existing resources for use in IaC scenarios.
47
47
* API producers could use `PUT` operations to create or update, but generally this approach is not recommended due to the destructive nature of `PUT`'s replace semantics.
48
-
* API producers could to use `UPSERT` with a primary (client-provided) key and this may be appropriate for some scenarios. However, the recommendation is for resources to support creation using `POST` and a service-generated primary key, for consistency reasons.
48
+
* API producers could use `Upsert` with a primary (client-provided) key and this may be appropriate for some scenarios. However, the recommendation is for resources to support creation using `POST` and a service-generated primary key, for consistency reasons.
49
49
* API producers may annotate entity sets, singletons and collections to indicate that entities can be "upserted". The example below shows this annotation for the `groups` entity set.
50
50
51
51
```xml
@@ -94,6 +94,7 @@ Create a new group, with a `uniqueName` of "Group157". In this case, this group
0 commit comments