GraphQL publica su especificación para usarlo sobre HTTP con un tipo de respuesta propio
GraphQL presentó la primera versión de un documento que define cómo funciona sobre HTTP, con un tipo de contenido propio y un código de estado para respuestas parciales.
Redacción PicoTecno
2 min de lectura
(graphql.org)
Según informó graphql.org, el proyecto lanzó la primera versión de la especificación GraphQL over HTTP, un documento complementario que indica cómo deben enviarse y recibirse las consultas y respuestas de GraphQL cuando se usa el protocolo HTTP (el mecanismo base de la comunicación web).
GraphQL, un lenguaje de consultas para interfaces de programación creado en 2015, se diseñó sin atarse a un medio de transporte en particular. Hasta ahora, esa libertad hacía que los equipos que lo usaban con HTTP implementaran cada uno a su manera el envío de datos, lo que complicaba la interoperabilidad con otras herramientas de HTTP y el monitoreo de los servicios.
La novedad más visible es un nuevo tipo de contenido, application/graphql-response+json. Hasta el momento, muchos servidores usaban application/json, lo que dificultaba distinguir una respuesta válida de GraphQL de un error generado por un proxy, una caché u otro intermediario de red. Para sortear el problema, la mayoría respondía con el código 200 en todos los casos, algo que la propia documentación reconoce que dificulta el seguimiento del estado de un servicio.
Códigos de estado y respuestas parciales
Con el nuevo tipo de contenido, un cliente sabe que puede interpretar el cuerpo como una respuesta GraphQL bien formada sin importar el código de estado. La especificación recomienda qué códigos usar en cada situación, aunque los implementadores pueden elegir otros siempre que respeten la regla general. Entre los ejemplos que muestra el anuncio aparecen el 200 para una respuesta exitosa y el 422 para un error en la solicitud, como una consulta a un campo que no existe.
Además, el documento introduce el código 294 Partial Success, pensado para los casos en que la respuesta incluye datos y errores al mismo tiempo. Las notas no normativas de la especificación amplían esa explicación.
El anuncio también menciona temas que quedan para más adelante. El IETF, el grupo que impulsa estándares de Internet, pasó el método QUERY de HTTP a estado de propuesta de estándar, y GraphQL planea incorporarlo en una próxima revisión de su especificación. Algo similar ocurre con los documentos persistidos, una técnica usada desde antes de la apertura del código de GraphQL para mejorar rendimiento, seguridad y monitoreo, que el proyecto quiere estandarizar junto a la comunidad. Por último, el procesamiento por lotes de solicitudes podría resultar especialmente útil en esquemas compuestos, como los de Federation, o cuando se consultan esquemas que no controla quien hace la solicitud.
Según la publicación, muchos frameworks y bibliotecas de GraphQL ya admiten la nueva especificación, por lo que es probable que algunos usuarios la estén utilizando sin saberlo. Quienes desarrollan bibliotecas están invitados a probarla.
