Google dévoile une nouvelle API pour Gmail

Google dévoile une nouvelle API pour Gmail

Enfin ?

Avatar de l'auteur
David Legrand

Publié dans

Internet

30/06/2014 4 minutes
8

Google dévoile une nouvelle API pour Gmail

En marge de ses nombreuses annonces de la semaine dernière à l'occasion de la Google I/O, le géant du web a annoncé une nouvelle API pour Gmail. Celle-ci permettra d'intéragir avec un service tiers de manière plus simple, et s'inscrit dans la lignée de l'ouverture du service ces dernières années. Mais attention aux dérives.

Si Google a largement construit l'intérêt de ses services en ligne sur leur ouverture aux développeurs via de très nombreuses API, Gmail faisait office de mauvais élève en étant encore assez limité sur ce point. Il faut dire que comme tout webmail qui se respecte, il proposait une connexion via le protocole IMAP, ce qui pouvait sembler suffisant à certains.

IMAP est un bon protocole pour les clients, pas pour les services

Une procédure déjà exploitée par tous les clients actuellement sur le marché, mais aussi via des outils tiers comme Boomerang ou Sanebox dont nous vous parlions lors de l'une de nos analyses l'année dernière. Mais si la volonté d'ouvrir ses emails à un service tiers peut s'avérer parfois nécessaire, la façon de faire n'est pas toujours la plus sûre. En effet, l'utilisation du protocole IMAP impose en général d'indiquer le login et le mot de passe du compte, tout en donnant un accès total tant en lecture qu'en écriture. Bref, il faut avoir une certaine confiance pour procéder de la sorte.

 

Pour palier ce problème, il existe néanmoins des solutions. Les réseaux sociaux et autres services en ligne exploitent en effet depuis longtemps des protocoles comme OAuth qui permettent de déléguer un accès à une application sans lui donner les clefs de votre compte. L'utilisateur peut révoquer cet accès à tout moment ou en limiter son champs d'action.

Des API existent déjà chez la concurrence, Gmail cherche à s'adapter depuis 2010

Les principaux concurrents de Google ont d'ailleurs déjà largement implémenté des solutions de ce genre. C'est notamment le cas de Yahoo avec son Web Mail Service ou de Microsoft avec Outlook.com IMAP, qui accepte une authentification via OAuth 2.0. C'est d'ailleurs cette méthode qui est exploitée par le service Unroll.me qui a fait grand bruit il y a quelques mois de cela. 

 

Désormais, ce sera aussi le cas pour Google avec Gmail. Notez qu'en 2011, la société avait déjà montré quelques signes d'ouverture, notamment avec la mise en place d'un flux accessible simplement. Elle proposait aussi depuis 2010 le fait de pouvoir se connecter via OAuth tout en exploitant les fonctionnalités IMAP avec différents niveaux d'autorisation.

 

Une nouvelle API qui vient en complément de ce qui existe déjà

Mais le but est ici d'aller plus loin. Google veut proposer plusieurs types de solutions pour Gmail comme le montre son nouvel espace dédié aux développeurs : l'intéraction avec le support de Schema.org, l'extension avec les gadgets qu'il est possible de développer, la gestion avec le duo IMAP/SMTP pour les clients mail et l'intégration avec sa nouvelle API. Google ne veut pas remplacer telle ou telle possibilité, mais bien venir la compléter avec une solution différente, pour des besoins spécifiques et adaptés aux fonctionnalités propres à Gmail.

 

Tous ceux qui développent des services tiers sans avoir besoin de la complexité ou de la standardisation d'IMAP pourront donc y trouver leur bonheur. Quatre niveaux d'accès sont proposés :

  • Accès complet
  • Lecture seule
  • Lecture et écriture, mais pas de suppression
  • Envoi de mails et de brouillons uniquement

Il faudra donc être attentif à celui qui est demandé par les outils qui exploiteront cette API, tout comme il fallait l'être pour les précédentes intégration utilisant OAuth ou les solutions concurrentes.

 

Un site dédié aux développeurs a bien entendu été mis en ligne pour ceux qui voudraient en savoir plus, ainsi qu'une vidéo complète de présentation que vous retrouverez ci-dessous :

 

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

IMAP est un bon protocole pour les clients, pas pour les services

Des API existent déjà chez la concurrence, Gmail cherche à s'adapter depuis 2010

Une nouvelle API qui vient en complément de ce qui existe déjà

Fermer

Commentaires (8)


Ne serait ce pas plus intéressant de faire évolué le protocole IMAP ou de faire un nouveau standard ? Parce que supprimé la synchro Exchange Active Sync sous prétexte que c’est proprio pour pousser une API proprio à la place de l’IMAP c’est <img data-src=" />








arno53 a écrit :



… pousser une API proprio …





C’est du web service. J’ai du mal à voir en quoi l’API est proprio.







arno53 a écrit :



… à la place en plus de l’IMAP …





Je n’ai vu marqué nul part que ça allait remplacer IMAP.









arno53 a écrit :



Ne serait ce pas plus intéressant de faire évolué le protocole IMAP ou de faire un nouveau standard ? Parce que supprimé la synchro Exchange Active Sync sous prétexte que c’est proprio pour pousser une API proprio à la place de l’IMAP c’est <img data-src=" />







Non car là ce n’est pas la même chose. Il s’agit d’une API Gmail pas d’un protocole de communication. Le protocole utiliser est standard c’est du REST.



En terme de sécurité, ce genre d’API est malheureusement la plus grosse porte d’entrée pour des tiers à tout le contenu des utilisateurs. Même si l’API est bien faite, ça peut toujours induire une prise de contrôle possible si l’autorisation est possible en un clic par l’utilisateur. ( Vu le nombre de personnes qui cliquent sans lire les messages … )



Je ne veux pas préjuger trop vite, il faut laisser du temps et voir concrètement comment cela sera implémenté mais je reste évidemment très méfiant …








PressAnyKey a écrit :



C’est du web service. J’ai du mal à voir en quoi l’API est proprio.





Je n’ai vu marqué nul part que ça allait remplacer IMAP.





Non pas remplacé mais placé là un peu en legacy.



Si l’IMAP n’est plus adapté à la gestion des mails d’aujourd’hui pourquoi ne pas le faire évolué ou créer un protocole extensible plutôt que proposé juste une API limité aux seuls besoin de GMail …



Je ne crois pas avoir vu d’infos dans la news sur ce point : est-ce payant d’utiliser l’API ? Ou y-a-t-il des limitations quelconques en termes de licence ?








arno53 a écrit :



Non pas remplacé mais placé là un peu en legacy.





“en legacy” <img data-src=" />







arno53 a écrit :



Si l’IMAP n’est plus adapté à la gestion des mails d’aujourd’hui pourquoi ne pas le faire évolué ou créer un protocole extensible plutôt que proposé juste une API limité aux seuls besoin de GMail …





Développer un protocole ou une API web ce n’est pas du tout le même investissement en temps et en ressources. Ils avaient besoin de répondre rapidement à une demande des utilisateurs qui traînait depuis des lustres, ils ont fait au plus rapide. De plus je ne vois pas pourquoi ça serait à Google de développer un protocole de remplacement à IMAP.









PressAnyKey a écrit :



“en legacy” <img data-src=" />



Développer un protocole ou une API web ce n’est pas du tout le même investissement en temps et en ressources. Ils avaient besoin de répondre rapidement à une demande des utilisateurs qui traînait depuis des lustres, ils ont fait au plus rapide. De plus je ne vois pas pourquoi ça serait à Google de développer un protocole de remplacement à IMAP.





Quand quelque chose n’évolue plus au profit de quelque chose d’autre plus récent qui deviendra la voie royal pour interagir avec le service pour moi ca sonne comme du legacy… Un peu a la manière de Win32 sur Windows, c’est là, ça marche mais dans 10 ans on en entendra plus parler …



C’est vrai que Google n’a pas a faire une nouvelle norme tout seul mais c’est la fin du support d’exchange pour Gmail au profit de solution ouvertes qui me fait rire … Aujourd’hui cette solution ouverte est relégué au second plan …



Du coup avec ce genre de messages j’espère que les organismes chargés des standards vont au moins lancé un groupe de discussion pour ne pas laissé les standards devenir l’outils vieillot du pauvre <img data-src=" />