OlgaPodo

Evolvable Graph API design

1

We are currently working on updating a set of guidelines specific for Graph APIs. We also observed a need to list the best practices and patterns for evolvable API designs...

In our examples we use BadRequest error code which supposed to be in camel case and potentially use predefined enum type https://github.com/microsoft/api-guidelines/blob/vNext/graph/GuidelinesGraph.md#error-handling

Add strong recommendation to avoid openType and consider [Microsoft Graph extensions plan proposal.docx](https://microsoft-my.sharepoint-df.com/:w:/p/dkershaw/EYOFKrcI4-hHj_jBcdL0iuIBLZEl3q6tEKo01I4nebyXsg?e=MYJS97) Comment: we made the distinction between using an open type where customers could add custom properties (which...

Error message localization

1

It's be great for Microsoft API REST API guidelines to be explicit about using Accept-Language header and localized detailed error message like above.

Expand may be an expensive option in this case therefore a requirement doe expand should state if there is a vialble use case.

State machine pattern

1

Create a new pattern on how to design Graph API for modeling a resource with defined state machine

Clarify when to group stuff in a complex type

We identified two distinct types of the soft DELETE behavior: 1) when an item flagged as deleted and 2) when an item is moved to a 'recycle bin' location. These...