Microsoft Graph o endpoints REST heredados: una guía de decisión para 2026

La pregunta está ligeramente incorrecta

Cualquiera que conecte una aplicación a Microsoft 365, Entra ID, Teams u Outlook terminará buscando alguna forma de preguntarse “¿REST API o Microsoft Graph?”. Parece una elección razonable entre dos opciones, pero no lo es del todo. Microsoft Graph es en sí mismo una REST API. Lo que la gente suele querer saber es esto:

¿Debería seguir utilizando los endpoints REST antiguos específicos para cada servicio (Azure AD Graph, la REST API de Outlook, SharePoint REST, EWS y similares), o pasar a la API unificada Microsoft Graph?

En 2026 esa pregunta tiene plazos reales. Microsoft ha invertido aproximadamente tres años en descontinuar las APIs fragmentadas y orientar a todos hacia Graph, y algunas de esas descontinuaciones están a solo unas semanas de ocurrir. A continuación encontrará la clasificación de los nombres, una verificación del estado de lo que aún funciona, una comparación lado a lado y un proceso de toma de decisiones que puede aplicar tanto a nuevas versiones como a integraciones antiguas.

Clasificación de los nombres

REST es un estilo arquitectónico. No es un producto que se instala. Una API que utiliza verbos HTTP como GET, POST, PATCH y DELETE, trata los elementos como recursos mediante URL y generalmente intercambia datos en formato JSON puede considerarse adecuadamente RESTful. Según esa definición, Microsoft Graph, Azure AD Graph, la ya descontinuada Outlook REST API y SharePoint REST cumplen con los requisitos.

Microsoft Graph es la única API REST que abarca tanto Microsoft 365 como Entra ID. No es necesario pasar de un punto de conexión para el correo, a otro para los archivos y a un tercero para los datos de directorio. Todo se encuentra bajo https://graph.microsoft.com/: usuarios, grupos, correo, calendarios, chats de Teams, archivos, alertas de seguridad y, recientemente, también agentes de IA.

Por lo tanto, la comparación útil es entre el Graph unificado y las interfaces REST antiguas específicas de cada servicio. La situación actual de esas APIs antiguas es muy importante, ya que la situación ha cambiado rápidamente en el último año.

Qué sigue funcionando en 2026

Si algo que posees sigue haciendo referencia a graph.windows.net, ya estás retrasado; a partir de mediados de julio de 2026, esa opción dejará de estar disponible en un par de semanas. La antigua API REST de Outlook ya no existe desde hace más de dos años. El acceso de terceros a EWS a través de Exchange Online será eliminado este otoño. Casi todos los argumentos que alguna vez justificaron seguir utilizando un endpoint REST nativo ya han expirado o están a punto de hacerlo.

Microsoft ha modificado varias de estas fechas en el pasado, así que confirma la fecha límite actual en Microsoft Learn antes de planificar una migración alrededor de ella. Sin embargo, la dirección general no ha cambiado en años: todo se consolida en Graph.

Graph frente a los endpoints heredados

Tres diferencias son las más importantes en el trabajo diario.

Autenticación

A lo largo de más de una década, el legado ha ido acumulando una serie de opciones de autenticación: Autenticación Básica, NTLM, Kerberos y el Servicio de Control de Acceso de Azure en el que dependían los complementos de SharePoint. Para las cargas de trabajo de Microsoft 365, todas esas opciones ya han sido retiradas. Graph solo ha aceptado OAuth 2.0 a través de Microsoft Entra ID. Esto ofrece un único método para obtener tokens, un único modelo de permisos y un único lugar para auditar quién puede acceder a qué. Los administradores obtienen una mejora en la seguridad, y no solo los desarrolladores, una API más adecuada.

Consultas y agrupamiento

Una solicitud a Graph, como la que se muestra a continuación, puede filtrar, reducir y paginar el correo en un único viaje:

GET https://graph.microsoft.com/v1.0/me/messages
    ?$select=subject,receivedDateTime,from
    &$filter=receivedDateTime ge 2026-07-01T00:00:00Z
    &$top=25
    &$orderby=receivedDateTime desc

Con los endpoints más antiguos y menos flexibles, a menudo se necesitaban varias llamadas específicas o filtros en el cliente para obtener el mismo resultado. Al agregar $batch, se pueden incluir hasta 20 operaciones independientes en una sola solicitud HTTP, combinando lecturas y escrituras en tipos de recursos completamente diferentes.

Limitación de velocidad

Graph aplica varios límites al mismo tiempo: por aplicación entre todos los inquilinos, por inquilino entre todas las aplicaciones, y por aplicación dentro de un mismo inquilino. Las cifras reales varían según el servicio, ya que el correo, los archivos, los directorios y la mensajería de Teams establecen sus propios límites. El límite que se alcance primero genera el código 429 Too Many Requests junto con un encabezado Retry-After que indica cuánto tiempo hay que esperar. En comparación con las APIs antiguas, donde el control de velocidad a menudo no estaba documentado y los límites se descubrían en producción, esto representa un gran avance. El consejo sigue siendo válido: utilice $select para obtener solo los campos necesarios, prefiera las consultas por lotes y de tipo delta a las consultas periódicas, y respete siempre el valor de Retry-After en lugar de intentar de nuevo de inmediato.

Donde aún tiene sentido usar algo distinto a Graph

Graph aún no abarca todo, y algunos casos realmente requieren un API diferente.

• Administración detallada de sitios de SharePoint. Los detalles completos a nivel de permisos, algunas operaciones de grupos de sitios y partes de la gestión de esquemas de tipos de contenido y listas solo están disponibles en SharePoint REST bajo _api/web/.... Los proyectos de SharePoint maduros suelen realizar las tareas diarias relacionadas con archivos, listas y unidades de almacenamiento a través de Graph y utilizan SharePoint REST únicamente para lo que falta.
• Componentes web SPFx. El entorno de ejecución de SharePoint Framework ya proporciona un contexto de SharePoint REST listo para usar, por lo que para personalizaciones dentro de la página suele ser la opción más sencilla, aunque el mismo componente web también puede hacer llamadas a Graph.
• Exchange Server local. El bloqueo de octubre de 2026 solo se aplica a Exchange Online, por lo que EWS sigue funcionando con Exchange local. Para una configuración de correo completamente local, la verdadera opción es EWS o migrar primero a Exchange Online.
• Tareas administrativas grandes y puntuales. La limpieza masiva de permisos, la generación de informes para usuarios y la provisión de sitios a gran escala suelen realizarse con herramientas de nivel superior como PnP PowerShell, la cual a su vez utiliza internamente una combinación de Graph y SharePoint REST.

Más allá de esos casos específicos, un proyecto completamente nuevo tiene pocas razones técnicas para comenzar este año utilizando uno de los antiguos puntos de conexión por servicio, ya que la mayoría ya están fuera de servicio o en proceso de descontinuación.

Cómo decidir

Evalúe cualquier nueva integración mediante estas preguntas:

1. ¿Se trata de una versión recién lanzada? Utilice Microsoft Graph. Las nuevas funciones se integran primero allí, y es la única plataforma en la que Microsoft sigue invirtiendo.
2. ¿Algún aplicación existente hace llamadas a Azure AD Graph, la API REST de Outlook o complementos de SharePoint basados en ACS? Outlook REST y ACS ya han superado su período de soporte, y Azure AD Graph dejará de funcionar el 31 de julio de 2026. Considere esto como una tarea urgente.
3. ¿Algún aplicación de terceros utiliza EWS con Exchange Online? Microsoft comenzará a bloquear esas llamadas el 1 de octubre de 2026. Empiece a migrar ahora a los puntos de extremo de correo y calendario de Graph.
4. ¿Necesita alguna función de SharePoint que Graph aún no tenga? Utilice SharePoint REST para esa llamada específica y Graph para todo lo demás. Revise primero la documentación de SharePoint-in-Graph, ya que la lista de funcionalidades faltantes se va acortando constantemente.

¿El entorno es solo on-premises? EWS y otros protocolos on-premises siguen siendo válidos allí. Graph está diseñado principalmente para la nube y no puede conectarse directamente a Exchange o SharePoint Server on-premises.

Para casi todos, esto se reduce a una regla: utilice Microsoft Graph, a menos que tenga una razón específica y documentada para no hacerlo.

La misma solicitud, entonces y ahora

Aquí se muestra la llamada obsoleta de Outlook REST v2.0, únicamente a efectos de comparación:

GET https://outlook.office.com/api/v2.0/me/messages
Authorization: Bearer {token}

Ese endpoint ha respondido con HTTP 410 Gone desde marzo de 2024. La versión Graph de la misma solicitud se ve así:

GET https://graph.microsoft.com/v1.0/me/messages?$select=subject,from,receivedDateTime&$top=10
Authorization: Bearer {token}

SharePoint REST, que sigue siendo compatible, lee los elementos de la lista de la siguiente manera:

GET https://{tenant}.sharepoint.com/sites/{site}/_api/web/lists/getbytitle('Documents')/items
Authorization: Bearer {token}
Accept: application/json;odata=verbose

Donde Graph admite la misma operación, la llamada se convierte en:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items
Authorization: Bearer {token}

La mecánica de HTTP es idéntica en ambas épocas. Lo que añade Graph es una URL base, un modelo de autenticación y una convención JSON, independientemente del servicio de Microsoft 365 con el que se esté interactuando.

Migrar desde una API heredada

Si acaba de darse cuenta de que algo en su tenant aún depende de una API en desuso, siga esta lista:

1. Descubra qué es lo que realmente la utiliza. Entra ofrece dos recomendaciones: “Migrar aplicaciones” y “Migrar principios de servicio”, que muestran el uso real de Azure AD Graph observado en su tenant durante los últimos 30 días. Esto es mucho mejor que adivinar a partir del código fuente.
2. Asigne permisos de forma explícita. Los permisos heredados no se traducen uno a uno a los alcances de Graph. Utilice las referencias oficiales de Microsoft para el mapeo de permisos en lugar de asumir que dos alcances con nombres similares son equivalentes.
3. Transfiera la autenticación a MSAL. Todo lo que aún utilice la antigua Biblioteca de Autenticación de Azure AD (ADAL) debe migrarse por separado, ya que ADAL ya no cuenta con soporte desde hace años.
4. Cambie los SDK, no solo las URLs. Los SDK oficiales de Graph para .NET, JavaScript y TypeScript, Python, Java, Go y PowerShell gestionan automáticamente el agrupamiento de solicitudes, las reintentos y la paginación. No escriba llamadas HTTP en bruto a menos que sea realmente necesario.
5. Tenga cuidado con la versión beta. Si una función solo está disponible en el endpoint Graph beta, su contrato puede cambiar sin previo aviso. Planifique esto o espere a que esté disponible para todos.
6. Identifique los errores 429 en el entorno de pruebas. Realice pruebas de carga con volúmenes de solicitudes realistas para detectar el límite de throttling antes de que lo hagan sus usuarios.
7. Indique la fecha límite real en su calendario y verifíquela contra la documentación en tiempo real de Microsoft justo antes de confiar en ella. Estas fechas ya han cambiado anteriormente, por lo que considere cualquier fecha que obtenga de fuentes externas, incluida esta página, como provisional.

Graph también es donde se gestionan los agentes de IA

Hay otra razón por la cual la brecha sigue aumentando. Graph se está convirtiendo en el plano de control para el ecosistema de agentes de IA de Microsoft. Durante 2026, Microsoft agregó puntos de conexión de Graph para gestionar los agentes y aplicaciones de Microsoft 365 Copilot, mantener un inventario de agentes y obtener informes más detallados sobre el uso de Copilot, además de funciones vinculadas a licencias más recientes como Agent 365. Nada de esto existe en Azure AD Graph, Outlook REST o EWS, y nunca existirá. Si su organización planea desarrollar extensiones para Copilot o agentes personalizados, esa es otra vía que solo conduce a Graph.

Qué implica esto para usted

La pregunta principal tiene una respuesta bastante clara para 2026:

• ¿Iniciar algo nuevo en Microsoft 365 o Entra ID? Utilice Microsoft Graph. Ya no existe ningún caso en el que un proyecto nuevo deba iniciarse mediante una API REST específica de un servicio obsoleto.
• ¿Mantener una integración antigua? Compárela con la tabla de estado anterior. Si involucra Azure AD Graph, Outlook REST, complementos de SharePoint basados en ACS o acceso a EWS de terceros, está trabajando bajo plazos límite, y algunos de esos plazos están muy cerca.
• ¿Le falta alguna funcionalidad de SharePoint en Graph? Utilice SharePoint REST solo para esa llamada específica y mantenga todo lo demás en Graph.

En 2018, cuando Microsoft realmente ejecutaba varias interfaces REST competidoras al mismo tiempo, “REST API o Graph” era un tema de debate razonable. Hoy en día se trata principalmente de una fase de consolidación. La unificación está casi terminada, y las alternativas están perdiendo relevancia.