Skip to content

Commit 3928589

Browse files
committed
Updated text and added examples
1 parent b46c94d commit 3928589

File tree

1 file changed

+81
-6
lines changed

1 file changed

+81
-6
lines changed

graph/patterns/navigation-property.md

Lines changed: 81 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -7,12 +7,23 @@ Microsoft Graph API Design Pattern
77
## Problem
88
--------
99

10-
Resources often contain information that identifies other related resources. Usually that information is contained in a returned representation as an id value. In order for a client to access the related resource it must request the primary resource, read the id value of the related resource and then construct a URL to the related resource using the Id value. This requires at least two round trips and requires the client know how to construct the URL to the related resource.
10+
It is often valuable to represent a relationship between resources in an API. This may be a many-to-one or a one-to-many relationship.
11+
12+
Relationships between resources are often implicitly represented by a property contained in one of the resources that identifies the other related resource. Usually that information returned in a representation as an id value and the property is named using a convention that identifies the target type of related resource. e.g. userId
13+
14+
In many-to-one relationships, for a client to access the related resource it must request the primary resource, read the id value of the related resource and then construct a URL to the related resource using the Id value and knowledge of how the property name maps to the related resource. This requires at least two round trips and requires the client know how to construct the URL to the related resource.
15+
16+
For both many-to-one and one-to-many relationships in order to retrieve information from both resources on both sides of the relationship requires at minimum two requests.
17+
18+
Requiring two round trips to access this information is inefficient for some applications and the lack of a formally described relationship limits the ability for tooling to take advantage of the relationship to improve developer experience.
1119

1220
## Solution
1321
--------
1422

15-
Navigation properties are an OData convention that allows an API designer to create a special kind of property in a model that references an related entity. In the HTTP API this property name translates to a path segment that can be appended to the URL of the primary resource in order to access a representation of the related resource. This prevents the client from needing to know any additional information on how to construct the URL to the related resource and the client does not need to retrieve the primary resource if it is only interested in the related resource. It is the responsibility of the API implementation to determine the Id of the related resource and return the representation of the related entity.
23+
Navigation properties are an [OData convention](https://docs.microsoft.com/en-us/odata/webapi/model-builder-untyped#navigation-property) that allows an API designer to describe a special kind of property in a model that references an related entity. In the HTTP API this property name translates to a path segment that can be appended to the URL of the primary resource in order to access a representation of the related resource. This prevents the client from needing to know any additional information on how to construct the URL to the related resource and the client does not need to retrieve the primary resource if it is only interested in the related resource. It is the responsibility of the API implementation to determine the Id of the related resource and return the representation of the related entity.
24+
25+
e.g. /user/{userId}/manager # many-to-one relationship
26+
/user/{userId}/messages # one-to-many relationship
1627

1728
Additionally, using the OData Expand query parameter, related entities can be transcluded into the primary entity so both can be retrieved in a single round trip.
1829

@@ -21,22 +32,86 @@ Additionally, using the OData Expand query parameter, related entities can be tr
2132

2233
In the current Microsoft Graph implementation, support for navigation properties is limited to entities within the same backend service or the user entity.
2334

35+
Navigation properties defined within an entity are not returned when retreiving the representation of an entity.
36+
2437
Implementing support for accessing the "$ref" of a navigation property allows a caller to return just the URL of related resource. e.g. `/user/23/manager/$ref`. This is useful when a client wishes to identity the related resource but doesn't need all of its properties.
2538

2639
## When to Use this Pattern
2740
------------------------
2841

29-
The use of navigation properties is preferred over
42+
### "has a" relationships
3043

31-
 
44+
The use of navigation properties is preferred over including an Id field to reference the related entity in a many-to-one relationship. Id values require a client to make two round trips to retrieve the details of a related entity. With a navigation property a client can retrieve a related entity in a single round trip.
45+
46+
Navigation properties are also useful when clients sometimes want to retrieve both the primary entity and the related entity in a single round trip. The `expand` query parameter makes this possible.
47+
48+
### "parent-child" relationships
49+
50+
Resources that contain a parent Id property in a child resource can utilize a navigation property in the parent resource that is declared as a collection of child resources. If desirable, a parent navigation property can also be created in the child resource to the parent resource. This is usually not necessary as the parent URL is a subset of child resource URL. The main use of this would be when retrieving child resources and choosing to expand properties of the parent resource so that both can be retrieved in a single request.
51+
52+
`/invoice/{invoiceId}/items/{itemId}?expand=parentInvoice(select=invoiceDate,Customer)`
53+
54+
One other use case is when child resources appear in a non-contained collection and there is a desire to access the canonical parent:
55+
56+
`/me/pinnedChannels/{channelId}/team`
3257

3358
## Example
3459
-------
3560

36-
*Provide a short example from real life*
61+
### Retrieving a related entity
3762

38-
 
63+
```http
64+
GET /users/{id}/manager
65+
```
66+
67+
### Retrieving a reference to a related entity
68+
69+
```http
70+
GET /users/{id}/manager/$ref
71+
```
72+
73+
### Retrieving an entity with a related entity included
74+
75+
```http
76+
GET /users/{id}?expand=manager
77+
```
3978

79+
### Creating an entity with a reference to a related entity
80+
81+
```http
82+
POST /users/{id}
83+
Content-Type: application/json
84+
85+
{
86+
"displayName": "Bob",
87+
"manager@bind": "https://graph.microsoft.com/v1.0/users/{someGuid}"
88+
}
89+
```
90+
91+
### Updating a related entity reference
4092

93+
```http
94+
PATCH /users/{id}
95+
Content-Type: application/json
4196
97+
{
98+
"displayName": "Bob",
99+
"manager@bind": "https://graph.microsoft.com/v1.0/users/{someGuid}"
100+
}
101+
```
102+
103+
 
104+
```http
105+
PUT /users/{id}/manager/$ref
106+
Content-Type: application/json
107+
108+
{
109+
"@OData.Id": "https://graph.microsoft.com/v1.0/users/{someGuid}"
110+
}
111+
```
112+
 
113+
### Clear a related entity reference
42114

115+
```http
116+
DELETE /users/{id}/manager/$ref
117+
```

0 commit comments

Comments
 (0)