markdown format

Author: XVincentX

graph/patterns/alternate-key.md

@@ -2,10 +2,11 @@
 
 Microsoft Graph API Design Pattern
 
-*The Alternate Key Pattern provides the ability to query for a single, specific resource identifiable through an alternative attribute (called key) that is not its unique identifier*
+_The Alternate Key Pattern provides the ability to query for a single, specific resource identifiable through an alternative attribute (called key) that is not its unique identifier_
 
 ## Problem
---------
+
+---
 
 All entities in our system are identified by an [UUID (Universally Unique Identifier)](https://en.wikipedia.org/wiki/Universally_unique_identifier) - which guarantees uniqueness. Often though, that same resource can also be uniquely identified by an alternative, more convenient attribute that provides a better developer experience.
 
@@ -15,24 +16,26 @@ While it is still possible to use the oData filter, such as
 
 `https://graph.microsoft.com/v1.0/users?filter=mail eq '[email protected]'`, the returned result is wrapped in an array that needs to be unpacked.
 
-
 ## Solution
---------
+
+---
 
 oData offers resource addressing via an alternate key using the same parentheses-style convention as for the canonical key, with one difference: single-part alternate keys MUST specify the key attribute name to unambiguously determine the alternate key.
 
 https://graph.microsoft.com/v1.0/users(0) - Retrieves the employee with ID = 0
 https://graph.microsoft.com/v1.0/users(email='[email protected]') Retrieves the employee with the email matching `[email protected]`
 
 ## When to Use this Pattern
-------------------------
+
+---
 
 This pattern works and makes sense when the alternate key is good enough to identify a single resource and provides an useful alternative to the client; while it does not work if the resultset has more than one element.
 
-In such case, we **strongly** advice to throw an exception and encourage the user to use `$filter` rather than returning the first result of the query 
+In such case, we **strongly** advice to throw an exception and encourage the user to use `$filter` rather than returning the first result of the query
 
 ## Example
--------
+
+---
 
 The same user identified via the alternate key SSN, the canonical (primary) key ID using the non-canonical long form with specified key attribute name, and the canonical short form without key attribute name
 
@@ -41,8 +44,3 @@ https://graph.microsoft.com/v1.0/users/1a89ade6-9f59-4fea-a139-23f84e3aef66
 https://graph.microsoft.com/v1.0/users(ssn='123-45-6789')
 
 https://graph.microsoft.com/v1.0/users(email='[email protected]')
-
-
-
-
-