[Office 365] Vue d’ensemble de l’API Office 365
Microsoft a travaillé depuis plusieurs mois à unifier le développement autour de l’écosystème Office, que cela soit pour la suite Office via les Apps, mais aussi pour Office 365 (l’offre pour les entreprise avec Exchange Online, Lync Online, SharePoint Online/OneDrive for Business, Dynamics CRM Online…).
Ce billet va se concentrer sur ce deuxième point afin de faire un petit tour d’horizon des API et outils fournis par Microsoft.
Une vision unifiée
A l’heure des Universal apps et de l’ouverture vers les différentes plateformes (de développements et d’utilisation), Office 365 propose une API basée sur REST et OData 4.0 pour les données, OAuth 2.0 pour la gestion de l’authentification et des autorisations (géré via Azure Active Directory). Il devient ainsi possible de développer pour Office 365 quelque soit votre environnement sans dépendre d’un outillage spécifique.
Cependant, parce qu’on aime bien avoir déjà des briques prêtes à l’emploi et gagner du temps, des SDK ont été publiés pour faciliter les développements sur Visual Studio (encore heureux !), Eclipse, Android Studio ou encore XCode.
En plus de cela, une bonne vingtaine de Starter Kits et d’exemples ont été publiés sur GitHub afin de tester et démarrer rapidement vos développements.
Mais ce qui est important est avant l’unification des API, car derrière Office 365, ce sont plusieurs produits qui, historiquement, ont évolué chacun à son rythme, avec des moyens de développements divers et variés (EWS – Exchange Web Services - pour Exchange, des Web services SOAP puis une API REST ainsi qu’un modèle objet serveur et client pour SharePoint, l’Azure AD Graph API…) manquant de consistance et nécessitant des connaissances particulières pour les exploiter. L’objectif est de faire abstraction de ce legacy pour avoir la même approche quelque soit le domaine désiré, et les mêmes techniques pour s’authentifier et déléguer les permissions afin d’avoir une approche applicative complète.
Une boite à outils bien fournie
Je le mentionnai précédemment, bien que vous disposiez d’une API REST, vous serez forcément tenté d’utiliser les SDK proposés afin de passer plus de temps sur votre application et moins sur la tuyauterie. Vous pouvez ainsi télécharger les outils de dev pour VS 2013 http://aka.ms/OfficeDevToolsForVS2013 afin d’avoir une intégration avancée au sein de l’IDE.
En plus de ces SDK, vous pouvez aussi commenter à développer et faire vos tests simplement à l’aide de votre navigateur. Vous disposez ainsi de 2 sites bac à sable :
- Office 365 OAuth Sandbox (https://oauthplay.azurewebsites.net/) pour la partie authentification / autorisation : vous pouvez vous authentifier sur un environnement de test ou sur le votre, récupérer les jetons d’accès et les utiliser pour faire des requêtes HTTP sur l’API (vous avez même des exemples de requête pré-calibrés)
- API Sandbox (https://apisandbox.msdn.microsoft.com/) pour écrire et tester votre code en C# ou en JavaScript (et peut-être dans le futur en Python, PHP ,Objective-C si vous êtes suffisamment nombreux à voter pour
). Ici aussi il est possible de fonctionner en mode environnement de test ou sur le votre
Mais que peut-on faire ?
L'API est découpée en plusieurs “capacités” (capabilities en anglais) correspondant à des éléments d’Exchange, de SharePoint et d’Azure Active Directory:
- Mail pour entre autre récupérer/rechercher des messages électroniques dans votre boite aux lettres, ou en envoyer bien sûr
- Calendar pour toute la gestion des calendriers: les siens mais aussi les calendriers partagés et les groupes de calendriers
- Contacts pour… gérer les contacts (oui oui)
- Files/MyFiles pour gérer les fichiers et répertoire de son OneDrive entreprise (attention : OneDrive for Business n’est pas le OneDrive consumer, c’est au final une bibliothèque de documents SharePoint légèrement personnalisé)
- RootSite/Sites, que vous ne retrouverez pas directement dans l’API Office 365, correspond en fait à l’API cliente SharePoint (REST ou managé)
- Discovery permet quand à lui de retrouver les différents points de terminaison (login/Mail/MyFiles,SharePoint…) quand on ne les connait pas forcément, dans les scénarios multi-tenants principalement (i.e. votre application sera distribuée auprès de plusieurs clients)
- Directory enfin correspond à l’API Azure AD Graph pour toutes les opérations sur les utilisateurs et les rôles
On remarque que tout n’est pas forcément encore disponible (nous n’avons pas les tâches Exchange ou Dynamics), mais cela laisse déjà de nombreux cas d’utilisations (affichage des prochains événements de mon calendrier, listing des emails contenant un mot clé ou d’une personne en particulier, récupération ou sauvegarde de fichiers dans son OneDrive…).
Une logique d’App
Pour finir, le développement Office 365 reprend la logique des Apps puisqu’il faudra passer par la case consentement des autorisations nécessaires à l’application (login/SSO, lecture et/ou écriture dans vos contacts, …). On retrouve cela lorsqu’on utilise les outils pour Visual Studio : vous connecterez votre projet à un environnement de test et vous spécifierez alors les permissions nécessaires pour son fonctionnement.
Evidemment, si vous faites appel à une action pour laquelle vous n’avez pas demandé le consentement de l’utilisateur, elle échouera ! Pour info, vous pouvez consulter toutes les applications pour lesquelles vous avez consenti des autorisations sur le site https://myapps.microsoft.com.
J’espère que ce petit aperçu vous donnera envie de regarder de plus près cette API et qui sait, de l’intégrer à vos applications, qu’elles soient Web ou client riche, avec des technologies Microsoft ou non !
Références :
Commentaires