Elige en función de quién consume la API y cuán variadas son sus necesidades de datos, no del hype. GraphQL gana cuando muchos clientes diversos necesitan dar forma a sus propios datos; REST gana cuando las peticiones son uniformes, cacheables y simples.
user -> posts -> comments) en lugar de N viajes de ida y vuelta de REST.GET de REST cachea trivialmente en todas las capas; GraphQL necesita persisted queries para acercarse.| Aspecto | GraphQL | REST |
|---|---|---|
| Over/under-fetching | Resuelto por diseño | Problema común |
| Caching HTTP/CDN | Difícil (requiere trabajo) | Nativo y fácil |
| Control de coste/DoS | Debes añadirlo | Naturalmente acotado |
| Flexibilidad del cliente | Alta | Baja |
| Complejidad del servidor | Mayor | Menor |
Tampoco son excluyentes: muchos sistemas exponen REST para endpoints públicos/cacheables y GraphQL para clientes internos ricos.
Los entrevistadores senior evalúan criterio, no lealtad. La respuesta sólida nombra los ejes —diversidad de clientes, necesidades de caching, madurez del equipo, superficie de DoS— y admite los costes reales de GraphQL (caching y control del coste de consultas) en lugar de venderlo como universalmente mejor.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar