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
When type casting is required in the API query, request or response, a fully
29
29
qualified type name is represented as concatenation of a namespace and a type
30
-
name. Consequently namespaces should be aligned with API category path segment.
30
+
name. For consistent user experience namespaces should be aligned with the corresponding API category path segment.
31
+
31
32
32
33
## When to Use this Pattern
33
34
34
35
API resource grouping creates a user-friendly experience keeping all resources
35
-
for a specific feature close together. It also allows generating smaller SDKs
36
-
and libraries and limits length of IDE prompts such as Intellisense.
36
+
for a specific feature close together. It also allows generating smallersmaller downloadable client components
37
+
and limits length of IDE prompts such as Intellisense.
37
38
38
39
We recommend creating a new namespace when a new top-level API category is
39
40
introduced.
@@ -42,10 +43,10 @@ introduced.
42
43
43
44
1. Microsoft Graph consistency requirements discourage using the same type
44
45
names for different concepts even within different namespaces. Microsoft
45
-
Graph type names must be descriptive and almost always unique within the API
46
-
surface.
46
+
Graph type names must be descriptive and unique within the API
47
+
surface without requiring full qualification.
47
48
48
-
2. Namespace must be consistent with API navigation path.
49
+
2. Namespace must be consistent with API category in the navigation path according to [Microsoft Graph REST API Guidelines](https://github.com/microsoft/api-guidelines/blob/vNext/graph/GuidelinesGraph.md#uniform-resource-locators-urls)
49
50
50
51
3. When type name is ambiguous and requires a namespace qualifier, changing
0 commit comments