Différences de fonctionnalités entre Azure AD Graph et Microsoft Graph
Cet article fait partie de l’étape 1 : passer en revue les différences d’API du processus de migration des applications.
De nombreuses fonctionnalités de Microsoft Graph fonctionnent de la même façon que leurs équivalents Azure Active Directory (Azure AD) Graph. Toutefois, quelques-uns ont changé ou amélioré. Dans cet article, vous allez apprendre à adapter vos applications pour tirer parti de ces différences.
Cet article explique comment Microsoft Graph gère :
- Extensions du schéma Directory
- Requêtes différentielles
- Traitement par lots
Extensions du schéma Directory
Si votre application utilise des extensions d’annuaire Azure AD Graph, vous pouvez continuer à utiliser les mêmes API de base (avec les URL de requête Microsoft Graph) pour :
- Gérez les définitions d’extension d’annuaire à l’aide de la ressource extensionProperty et des méthodes associées.
- Obtenez les propriétés d’extension disponibles à l’aide de l’action getAvailableExtensionProperties .
- Lire les valeurs d’extension à l’aide de GET et pour les utilisateurs, uniquement avec une
$selectrequête via le point dev1.0terminaison - Recherche sur les valeurs d’extension à l’aide de GET et
$filter - Mettre à jour les valeurs d’extension à l’aide de PATCH
- Supprimer des valeurs d’extension à l’aide de PATCH (défini sur Null)
Microsoft Graph fournit une expérience de développement améliorée des extensions de schéma, qui n’est pas aujourd’hui rétrocompatible avec les extensions d’annuaire Azure AD Graph. Pour en savoir plus, consultez Choisir un type d’extension pour votre application.
Approche de migration recommandée
Si votre application Azure AD Graph utilise des extensions d’annuaire, utilisez une approche incrémentielle pour migrer l’application vers Microsoft Graph.
Tout d’abord, basculez votre application vers l’utilisation des appels microsoft API Graph, mais laissez-la continuer à utiliser les extensions d’annuaire Azure AD Graph.
Ensuite, vous pouvez passer à l’utilisation des extensions de schéma Microsoft Graph. Dans certains cas, le basculement n’est pas approprié. Ne changez pas si :
- Votre application utilise des extensions d’annuaire créées via AD Connect
- Votre application définit les valeurs d’extension d’annuaire utilisées dans les revendications de jeton par d’autres applications
- Votre application définit les valeurs d’extension d’annuaire utilisées dans les règles d’appartenance dynamique
REMARQUE : L’utilisation des propriétés d’extension de schéma Microsoft Graph en tant que revendications dans un jeton à l’aide de revendications facultatives ou dans une règle d’appartenance dynamique n’est pas encore prise en charge.
Pour basculer vers le modèle d’extension de schéma Microsoft Graph le plus récent, vous devez :
- Définissez de nouvelles définitions d’extension de schéma à l’aide de Microsoft Graph.
- Mettez à jour l’application pour prendre en charge les nouvelles définitions d’extension de schéma.
- Migrez les données des propriétés d’extension d’annuaire Azure AD Graph vers les propriétés d’extension de schéma Microsoft Graph. La migration automatique des données n’est pas prise en charge.
Requêtes différentielles
Azure AD Graph et Microsoft Graph vous permettent de suivre les modifications à l’aide de requêtes. L’approche générale est similaire entre les deux API, mais la syntaxe est différente.
Azure AD Graph appelle ces requêtes différentielles, tandis que Microsoft Graph les appelle des requêtes delta.
Le tableau suivant met en évidence les principales similitudes et différences :
| Demande delta | Azure AD Graph | Microsoft Graph |
|---|---|---|
| Demande de données initiale | Utilise un paramètre de requête :GET /groups?deltaLink= |
Utilise une fonction :GET /groups/delta |
| Obtenir de nouvelles modifications | GET /groups?deltaLink={deltaToken} |
GET /groups/delta?$deltaToken={deltaToken} |
| Synchroniser à partir de maintenant | Utilise un en-tête HTTP personnalisé :ocp-aad-dq-include-only-delta-token: true |
Utilise un paramètre de requête :GET /groups/delta?$deltaToken=latest |
| Suivre les modifications apportées aux objets d’annuaire | Obtient les modifications pour plusieurs ressources (utilisateur et groupe) dans la même opération :GET /directoryObject?$filter=isof('User') or isof('Group')&deltaLink= |
Utilise des requêtes distinctes avec Microsoft Graph, une pour chaque ressource. |
| Obtenir les modifications des ressources et des relations | Toutes les demandes retournent des modifications de ressource et de relation, si la ressource a des relations. | GET /groups/delta?$expand=members |
| Réponse indiquant les éléments nouveaux et modifiés |
|
|
| Réponse indiquant les éléments supprimés | Indique un élément supprimé avec une propriété supplémentaire aad.isDeleted définie sur true. | Indique un élément supprimé avec l’annotation @removed . Il peut également contenir un code de raison, qui indique si l’élément est supprimé, mais peut être restauré ou définitivement supprimé. |
Si votre application stocke déjà des données d’état, envisagez d’utiliser la fonctionnalité de « synchronisation à partir de maintenant » pour gérer la transition vers les requêtes delta.
Traitement par lots
Azure AD Graph utilisait un système appelé messages MIME en plusieurs parties pour gérer le traitement par lots. Microsoft Graph utilise le traitement par lot JSON pour autoriser jusqu’à 20 demandes en une seule opération de traitement par lots. Le mécanisme de traitement par lot JSON est plus simple à utiliser, en particulier avec les bibliothèques d’analyse JSON. Il permet également de séquencer les opérations par lots. Toutefois, il n’est pas rétrocompatible avec l’approche de traitement par lots d’Azure AD Graph.