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/operations.md
+58-24Lines changed: 58 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,12 +6,11 @@ Microsoft Graph API Design Pattern
6
6
7
7
## Problem
8
8
9
-
Sometimes when modeling a complex business domain, API designers need to model a business operation that effects one or multiple resources and has additional semantic meaning that cannot be expressed by HTTP methods. Modeling the operation via HTTP methods on each individual resource might be either inefficient or expose internal implementation details. In addition, the operation might produce observable side effects.
9
+
Sometimes when modeling a complex business domain, API designers need to model a business operation that effects one or multiple resources and has additional semantic meaning that cannot be expressed by HTTP methods. Modeling the operation via HTTP methods on each individual resource might be either inefficient or expose internal implementation details.
10
10
11
11
## Solution
12
12
13
-
To address these use cases, API designers can use operational resources such as functions or actions.
14
-
If the operation doesn't have any side effects and MUST return a single instance of a type or a collection of instances, then the designer MUST use OData functions; otherwise, the designer can model the operation as an action.
13
+
To address these use cases, API designers can use operational resources such as functions or actions. If the operation doesn't have any side effects and MUST return a single instance of a type or a collection of instances, then the designer SHOULD use OData functions; otherwise, the designer can model the operation as an action.
15
14
16
15
## When to use this pattern
17
16
@@ -21,15 +20,14 @@ The operation pattern might be justified when a modeling operation represents on
21
20
22
21
- a change of a resource (i.e., increment the value of a property) rather than a state (i.e., the final value of the property)
23
22
- complex processing logic that shouldn't be exposed to the client
24
-
- operation parameters might convey a restricted set of option (i.e., a report that can has to specify a date range)
23
+
- operation parameters might convey a restricted set of option (i.e., a report that has to specify a date range)
25
24
- the operation leverage some service-side data not exposed to (or easily retrieved in context by) the user.
26
25
27
26
You can consider related patterns such as [long running operations](./long-running-operations.md) and [change tracking](./change-tracking.md).
28
27
29
28
## Issues and considerations
30
29
31
-
- Microsoft Graph does NOT support unbound actions or functions. Bound actions and functions are invoked on resources matching the type of the binding parameter. The binding parameter can be of any type, and parameter value MAY be Nullable.
32
-
For Microsoft Graph, actions and functions must have the `isBound="true"` attribute. The first parameter is the binding parameter.
30
+
- Microsoft Graph does NOT support unbound actions or functions. Bound actions and functions are invoked on resources matching the type of the binding parameter. The binding parameter can be of any type, and parameter value MAY be Nullable. For Microsoft Graph, actions and functions must have the `isBound="true"` attribute. The first parameter is the binding parameter.
33
31
34
32
- Both actions and functions support overloading, meaning a schema might contain multiple actions or functions with the same name. The overload rules as per the OData [standard](http://docs.oasis-open.org/odata/odata-csdl-xml/v4.01/odata-csdl-xml-v4.01.html#sec_FunctionOverloads) apply when adding parameters to actions and functions.
35
33
@@ -46,29 +44,65 @@ For Microsoft Graph, actions and functions must have the `isBound="true"` attrib
46
44
47
45
- The addition of a new mandatory not-nullable parameter to an existing action or function is a breaking change and is not allowed without proper versioning that is in accordance with our [deprecation guidelines](https://github.com/microsoft/api-guidelines/blob/vNext/graph/deprecation.md).
POST https://graph.microsoft.com/v1.0/me/messages/AQMkADNkMmMxYzIwLWJkOTItNDczZC1hNmYyLWUwZjk2ZTljMDQyNQBGAAAD1dY5iRo4x0_pEqop6hOrQAcAeGCrbYV1-kiG-z9Rv6yHMgAAAgEJAAAAeGCrbYV1-kiG-z9Rv6yHMgABRxeUKgAAAA==/forward
`forward` operation is modeled as an asynchronous action bound to the Graph `event` entity type because the operation represents a complex business logic processed on the server side.
`recent` function will query the most recent historyItems and then pull related activities therefore the operation represents a complex business logic processed on the server side. This operation doesn't change any server data and is a good fit for a function. The function is bound to the collection of `userActivity` entity type.
0 commit comments