outlook-restapi - developer - microsoft graph console

API REST de Outlook vs Microsoft Graph

Question

Estoy trabajando en una aplicación que necesita recuperar y editar eventos del calendario desde Outlook.com y Office 365. He visto que hay 2 opciones:

1. API REST de Outlook
2. Microsoft Graph

Parecen tener prácticamente la misma interfaz. Vi que la API REST de Outlook tiene soporte para notificaciones (webhooks), ¿no es así el gráfico de Microsoft? Entonces, ¿cuál elegir, cuáles son las ventajas / desventajas y por qué hay 2 API?

Answer 1

Para recuperar y editar eventos de calendario desde Outlook.com, funcionan los puntos finales de la API de Microsoft Graph y la API REST de Outlook. Si necesita Webhooks para una aplicación que planea usar en la producción, entonces necesita usar el punto final de Outlook REST API v2.0. Tenemos Webhooks disponibles en vista previa en Microsoft Graph, y estamos trabajando para lograrlos, para que pueda usarlos en sus aplicaciones de producción en el futuro. Si no necesita Webhooks para su aplicación, puede usar Microsoft Graph v1.0. Ambos puntos finales de Microsoft Graph y Outlook REST API son totalmente compatibles.

Ahora a por qué hay 2 puntos finales. La API REST de Outlook v1.0 se lanzó en octubre de 2014, y en noviembre de 2015 ofrecimos una versión v2.0 mejorada. Cuenta con las funciones de Outlook más recientes y expuestas a través de las API. Microsoft Graph v1.0 es un punto final conveniente, que lanzamos en noviembre de 2015, para que una aplicación acceda a la información de múltiples servicios de Microsoft, por ejemplo, Outlook, One Drive y Azure Active Directory. De hecho, cuando realiza una solicitud al punto final de Microsoft Graph v1.0 para cualquier característica de Outlook, la solicitud se enruta al punto final de Outlook REST API v2.0 bajo las carátulas. ¡Así que los conjuntos de API son iguales por diseño!

Estamos trabajando arduamente para cerrar cualquier brecha entre los puntos finales de API de servicio individuales (API REST de Outlook, API OneDrive, API de AAD Graph, etc.) y Microsoft Graph, pero habrá un pequeño delta por dos razones.

1. Los servicios individuales pueden tener entidades que tienen el mismo nombre pero que significan algo diferente. Por ejemplo, tanto Outlook como OneDrive tienen "carpeta" pero tienen significados diferentes. En este caso, debemos racionalizar el esquema de la API de Microsoft Graph para dejarle claro a qué entidad está accediendo cuando pasa por la API de Microsoft Graph. La carpeta estaba disponible en el punto final de Outlook API v1.0, y le cambiamos el nombre a MailFolder en el punto final de Outlook API v2.0, y también fue expuesta a través de Microsoft Graph API v1.0. Por lo tanto, es posible que siempre vea algunas características o API expuestas en un punto final de servicio individual durante algún tiempo antes de que la misma característica o API se exponga a través de Microsoft Graph.
2. Algunas funciones horizontales, por ejemplo, Webhooks pueden estar disponibles en Vista previa o GA antes en un punto final de servicio antes de que esté disponible en Microsoft Graph. Esto se debe a que la API de Microsoft Graph es un punto final más nuevo en comparación con los puntos finales de servicio individuales. Con el tiempo, se espera que esta lista de brechas se reduzca a cero.

Nuestra recomendación es que use Microsoft Graph siempre que tenga las características / API que necesita en producción para respaldar sus aplicaciones de producción, o al menos en Vista previa para respaldar el desarrollo de aplicaciones. Esto le facilita a usted, en el futuro, ampliar la funcionalidad de su aplicación que requiere acceso a múltiples servicios de Microsoft, sin cambiar los puntos finales. Puede usar puntos finales de servicio individuales como Outlook REST API si necesita una función que solo está disponible en el punto final de servicio individual, ya sea en producción (v2.0) o como vista previa (beta).