La trampa de la API REST: por qué tus flujos de Power Automate se arrastran a escala

By Mirko Peters · 2026-08-11

Al crear soluciones dentro del ecosistema de Microsoft 365, los desarrolladores y makers suelen caer en patrones cómodos. REST es la opción predeterminada para la mayoría de Power Pl…

Automatically translated with AI from the original post. Read the English original

Al crear soluciones dentro del ecosistema de Microsoft 365, los desarrolladores y makers suelen caer en patrones cómodos. REST es la opción predeterminada para la mayoría de los creadores de Power Platform, pero esconde trampas peligrosas como la limitación de solicitudes (errores 429) y el exceso de tamaño de payload. Si alguna vez has visto cómo un flujo de Power Automate avanza sin problemas durante las pruebas de desarrollo y, luego, se detiene por completo en producción, probablemente estés pagando los costes ocultos de las arquitecturas predeterminadas actuales. Para diseñar integraciones que soporten una escala de producción sin colapsar, debemos ir más allá de la comodidad superficial y evaluar los mecanismos de recuperación de datos disponibles.

Esta guía completa analiza la intersección entre CAML, REST y el formato JSON en Microsoft Lists y SharePoint. Veremos por qué la herramienta nueva y brillante no siempre es la adecuada, cómo esquivar las trampas de rendimiento y cuándo conviene recuperar técnicas clásicas para tu arsenal de arquitectura. Si quieres una inmersión en audio sobre este tema, no te pierdas nuestro episodio de podcast complementario, CAML vs REST vs JSON for SharePoint Lists.

¿Para quién es esto?

Los arquitectos, administradores y makers que trabajan dentro del ecosistema de Microsoft se enfrentan a retos de escalado particulares. Este artículo está pensado específicamente para:

• Creadores de Power Platform y administradores de SharePoint que quieren optimizar el rendimiento de sus entornos.
• Creadores de flujos de Power Automate que sufren tiempos de espera intermitentes y tiempos de ejecución lentos.
• Arquitectos empresariales responsables de listas que superan los 5000 elementos o que requieren filtros complejos de varios niveles.
• Equipos de desarrollo que luchan contra errores de limitación de solicitudes (429), el exceso de tamaño de datos o vistas de interfaz de usuario lentas.

Puntos clave

• CAML no está muerto: destaca en lógica AND/OR compleja, búsquedas anidadas, campos calculados y listas grandes, porque traslada el trabajo al backend de SharePoint.
• REST está en todas partes, pero no es invencible: es excelente para integraciones y herramientas en la nube, pero es propenso a la limitación de solicitudes, al exceso de tamaño de payload y a la unión de datos en el cliente bajo carga.
• El formato JSON = mejoras visuales inmediatas: perfecto para vistas rápidas y atractivas, hasta que el número de elementos crece y los navegadores se bloquean con la lógica pesada del cliente.
• Elige la herramienta según la tarea:
  • CAML → filtrado pesado en el servidor, grandes conjuntos de datos y selección estricta de columnas
  • REST → interoperabilidad, conectores, integraciones con Power BI, Teams y de terceros
  • JSON → mejoras de interfaz ligeras y tácticas (no para paneles a largo plazo)

Análisis en profundidad

Por qué CAML se resiste a morir

• Puntos fuertes
  • Filtros complejos y muy anidados con ejecución eficiente en el servidor
  • Selección precisa de columnas y paginación; evita arrastrar megabytes por la red
  • Funciona bien con los umbrales de vista de lista (5000 o más) cuando las consultas están indexadas o son específicas
• Aspectos a vigilar
  • XML verboso; curva de aprendizaje más pronunciada y documentación «moderna» más escasa
• Ideal para
  • Listas grandes, reglas de negocio intrincadas, campos calculados y filtros con múltiples búsquedas

REST: el valor predeterminado de doble filo

• Puntos fuertes
  • Universal, bien documentado y compatible con conectores (Power Automate, Power BI, Teams)
  • Payloads JSON sencillos; amplia cobertura de operaciones CRUD
• Aspectos a vigilar
  • Limitación de solicitudes (429), reintentos y ralentizaciones silenciosas a escala
  • Mucha manipulación de datos en el cliente (bucles, combinaciones, filtrado) → mayor latencia
  • Las escrituras por lotes requieren una orquestación cuidadosa y gestión de errores
• Ideal para
  • Integraciones, paneles, escenarios entre nubes y automatizaciones rápidas de conexión

Formato JSON: ¿personalización de la interfaz o trampa oculta?

• Puntos fuertes
  • Mejoras visuales rápidas y con poco código (indicadores de estado, barras, iconos, botones)
  • Permite a los makers crear interfaces sin SPFx personalizado ni compilaciones de aplicaciones
• Aspectos a vigilar
  • El coste de rendimiento en el cliente crece con el número de elementos y las condiciones anidadas
  • Mantenimiento: el formato complejo se convierte en «espagueti de llaves»
  • Los cambios de la plataforma pueden romper trucos ingeniosos; no lo uses para «ocultar» permisos
• Ideal para
  • Listas pequeñas y medianas, vistas tácticas, paneles temporales y tableros internos

Marco de decisión (rúbrica rápida)

1. ¿Filtros complejos o listas enormes? Empieza por CAML.
2. ¿Necesitas integraciones o amplio soporte de herramientas? Usa REST, pero haz pruebas de carga para detectar la limitación de solicitudes (throttling).
3. ¿Necesitas pulir la interfaz hoy mismo? Aplica JSON con moderación; mantén la lógica sencilla y las vistas ligeras.
4. Preparación para producción: indexa las columnas clave, minimiza los campos devueltos y prueba con datos a escala de producción.
5. Seguridad: configura permisos reales; no intentes «ocultar» datos con trucos de formato.

Lista de verificación de rendimiento y resiliencia

• Indexa las columnas usadas en filtros y ordenaciones
• Devuelve solo los campos necesarios (select/expand mínimo)
• Usa CAML para lógica de varias capas y filtrado estricto en el servidor
• Para REST: implementa reintentos con backoff exponencial, paginación por bloques y reintentos idempotentes
• Evita bucles en el cliente con cargas grandes; traslada el trabajo al servidor siempre que sea posible
• Mantén el formato JSON al mínimo; prueba con recuentos reales de elementos y con navegadores y dispositivos antiguos
• Supervisa en producción: latencia, tasas de error 429, tamaños de payload y reintentos fallidos

Trampas reales más comunes

• Migraciones REST que superan las pruebas de desarrollo pero se colapsan con 40.000–75.000 elementos debido a la limitación de solicitudes y al tamaño de los datos
• Vistas con mucho JSON que se ven muy bien con 500 elementos pero se ralentizan notablemente con 10.000 o más
• Revisiones de seguridad que detectan metadatos expuestos por el formato que deberían haber sido filtrados por permisos

«Cuándo usar cada uno», en la práctica

• CAML: reglas de aprobación que combinan campos calculados y de búsqueda; AND/OR complejos; paginación segura frente a los umbrales
• REST: conexiones de Power BI, pestañas de Teams, conectores de terceros y automatizaciones entre servicios
• JSON: panel ejecutivo de estados, codificación rápida por colores y botones de enlace; a corto plazo y de baja complejidad

Conclusión

Elegir la arquitectura adecuada para tus listas de SharePoint e integraciones con Power Automate no consiste solo en hacer funcionar una prueba de concepto en tu sitio de pruebas local. Consiste en entender cómo se comportarán tus soluciones cuando miles de registros, consultas simultáneas de usuarios y cargas de datos empresariales pongan a prueba tu código. Tanto si te apoyas en la potencia del lado servidor de CAML, en el alcance universal de las API REST o en el atractivo visual del formato JSON, conocer sus límites de escalado es lo que separa una aplicación frágil de un sistema empresarial resiliente y apto para producción. Para profundizar en estos compromisos técnicos y escuchar anécdotas reales del campo, no dejes de escuchar el episodio del podcast complementario: CAML vs REST vs JSON for SharePoint Lists.

Llamada a la acción

¿Tienes un fragmento de CAML especialmente útil, una anécdota sobre limitación de REST o un truco ingenioso con JSON? Compártelo: tu solución alternativa podría ahorrarle problemas a otra implantación.