Header Ads Widget

Ticker

6/recent/ticker-posts

¿REST sigue siendo un estilo de API relevante?

 


¿Qué tipo de estilo de API deberías usar? Desde SOAP hasta REST , GraphQL y nuevos estilos como gRPC , existen muchos estándares en competencia para diseñar API y la forma en que los consumidores interactúan con ellas. Hemos escrito sobre cada uno de ellos antes, pero a medida que la industria cambia rápidamente, siempre hay nuevas preocupaciones y oportunidades para comparar.

En una charla reciente en nuestra  Cumbre de Austin , James Higginbotham , experto en API / microservicios y consultor de LaunchAny , ofreció una descripción general de los estilos de diseño de API más populares  Dado que REST ha sido un estándar de diseño de facto durante algún tiempo, James exploró nuestro panorama actual de diseño de API para ver si REST todavía merece el título de campeón.

Todo se reduce a una competencia menor y más a un estudio sobre cómo los objetivos comerciales determinan las decisiones de estilo API . En este artículo, dejaremos a un lado los "concursos de popularidad" y consideraremos los estilos de API desde el punto de vista de lo que es mejor para los consumidores de API. Especialmente con el aumento de la presión sobre los administradores de API web para que produzcan API , muchos administradores están buscando formas de crear experiencias de desarrollador sorprendentes que no solo atraigan a los usuarios de desarrolladores, sino que también creen integraciones duraderas.

Este artículo se inspiró en la charla de James Higginbotham en la Cumbre de Austin de las API nórdicas de 2018:

Diapositivas

Las API resuelven una variedad de casos de uso

james-higginbotham_launchany

James Higginbotham de LaunchAny habló en las API nórdicas en Austin en junio, arrojando luz sobre las preocupaciones de diseño de API.

Lo primero que observa James es que la amplitud funcional de las API es amplia: realmente se pueden usar para resolver muchos casos de uso diferentes . Dado que la experiencia del cliente, la experiencia del trabajador y la experiencia del proveedor / socio pueden ser muy diferentes, naturalmente el estilo de API adecuado puede depender del escenario específico.

Fuera de las diferencias de los consumidores de API, también hay muchos comportamientos de interacción diferentes que afectan la implementación funcional. James enumera solicitud / respuesta, solicitud / reconocimiento, lote, publicación / suscripción y transmisión de mensajes como estilos de interacción. Por lo general, señala que las API generalmente se incluyen en la categoría de solicitud / respuesta, y que otras opciones se adaptan a circunstancias más matizadas.

De vuelta en la historia: de CORBA a GraphQL

Otra forma de ver realmente la amplitud de los diferentes estilos es profundizar en la historia de los estándares de comunicación web. James señala que en la década de 1990, el estilo de API B2B predominante era CORBA , un lenguaje de descripción de servicios. En palabras de James, el objetivo de CORBA era "crear interoperabilidad entre sistemas e incluso entre lenguajes de programación mediante la externalización de objetos".

SOAP fue la siguiente iteración. Se utilizó para la integración interna y, en lugar de los objetos, se trataron las cosas como servicios . SOAP tenía muchos beneficios: podía funcionar a través de un firewall, a través de múltiples protocolos de transporte y también funciona con devoluciones de llamada asincrónicas.

El poder del protocolo HTTP para API

Sin embargo, con el auge de los teléfonos inteligentes, las aplicaciones web y el IoT , la industria volvió a recurrir a HTTP . Hay una razón por la que HTTP ha sido una bendición para la comunicación de aplicación a aplicación y SaaS. De hecho, hay muchas razones.

Para cubrir un poco de los conceptos básicos, HTTP proporciona URL que nos permiten definir rutas de recursos . Hay verbos (GET, POST, PUT y PATCH) para permitir actuar sobre dichos recursos, hay códigos de respuesta y hay encabezados que nos permiten definir las relaciones cliente / servidor.

Yendo un poco más lejos, HTTP permite la negociación de contenido . Esto permite a las API negociar qué formatos de datos (JSON, XML, pueden agregar CSV, etc.) o idiomas que la API puede admitir y enviar a un cliente. HTTP también permite el almacenamiento en caché, ETags, solicitudes condicionales y control de simultaneidad.

¿Por qué entender los entresijos de HTTP? Bueno, aunque hemos creado una gran cantidad de soporte en HTTP para lograr muchas funciones, James ve que:

"La gente está canalizando la semántica del protocolo dentro de HTTP, ¡cuando realmente podrían usar HTTP!"

En general, es importante comprender los protocolos que utilizamos para transportar datos; como señala James, a menudo no pensamos en estas cosas cuando hablamos de estilos de diseño para API. Con una mejor comprensión de las funciones HTTP , los profesionales de API podrían ayudar a mejorar el rendimiento y la solidez de la API.

Lea también los artículos de James El poder de HTTP para API y la Parte 2

Comparación de estilos de API (no un Smackdown)

Como dice James, el objetivo de cualquier gran desarrollador o arquitecto es:

"Observamos y entendemos contextualmente lo que se ofrece, y luego preguntamos si eso se ajusta a nuestro caso de uso específico: el contexto en el que los consumidores lo usarán".

Por lo tanto, echemos un vistazo a cada estilo de API para ver en qué tipo de caso de uso encaja.

GraphQL

Como hemos cubierto antes, GraphQL permite una API más expresiva. Permite a los consumidores seleccionar recursos específicos para realizar consultas, lo que aumenta la solidez de una sola llamada a la API. Aunque GraphQL estandarizó este estilo, James señala que en el pasado también se realizó un estilo de interacción de parámetros de consulta similar en Linkedin.

GraphQL es ideal para datos jerárquicos . Además, con la selección a nivel de campo, la escritura fuerte y la introspección, GraphQL tiene muchos atributos que lo convierten en un ajuste sólido para las API de front-end .

Algunos aspectos negativos incluyen la aplicación limitada de seguridad en los puntos finales y las herramientas de operaciones limitadas. Además, debido a que GraphQL usa POST, es como SOAP en el sentido de que no puede almacenar en caché las respuestas. La falta de capacidad de almacenamiento en caché y flexibilidad para los tipos de contenido podría restringir una API; una razón en contra de la adopción total para algunos grupos.

BENEFICIOSINCONVENIENTES
Soporte de datos jerárquicosAplicación limitada de la seguridad del punto final
Selección a nivel de campoHay herramientas disponibles , pero son limitadas
Escritura fuerteInconsistencias en las recomendaciones
IntrospecciónFalta de caché
Falta de flexibilidad para los tipos de contenido.
Para obtener más información, lea nuestro libro electrónico sobre GraphQL: GraphQL o Bust

gRPC

Desarrollado por Google Cloud, gRPC es un marco de trabajo RPC de código abierto. Con un IDL (lenguaje de descripción de interfaz) similar a CORBA, gRPC usa un protobuf para ejecutar a través de generadores para crear un backend. James señala que gRPC es una buena opción para la implementación dentro de la organización , y afirma que una red más pública y orientada al cliente puede ser un poco más difícil de escalar si se usa gRPC.

Para James, las desventajas de gRPC tienen que ver con sus generadores de código , con quienes tendrás que ser muy amigable. Si está trabajando con muchos lenguajes de programación diferentes, es posible que haya algunos matices entre los generadores que tendrá que aprender. Al igual que GraphQL, gRPC también viene con problemas de caché.

BENEFICIOSINCONVENIENTES
Alto rendimiento, baja latenciaManejo de errores limitado
Formato de mensaje de ProtobufHerramientas de DevOps limitadas
Generación de código (cliente y servidor)Generación de código inconsistente entre idiomas
Construir sobre HTTP / 2Falta de caché
Comunicación bidireccionalFalta de flexibilidad para los tipos de contenido.

DESCANSO

Cuando hablamos de REST , nos referimos a las restricciones descritas por Roy Fielding: la relación cliente-servidor, ausencia de estado, capacidad de caché, capas, código bajo demanda y tener una interfaz uniforme. James señala que CRUD, por otro lado, es un patrón de ciclo de vida que se aplica encima de REST ; no son uno en el mismo.

Una gran ventaja de usar REST es la capacidad de superponer y aplicar restricciones de caché. James describe cómo las capas son importantes porque afectan la arquitectura general de la plataforma. La mayoría de las plataformas requieren servidores de aplicaciones en el backend, equilibradores de carga y proxies inversos en el front-end, y la capacidad de enviar datos a CDN (redes de entrega de contenido) en el borde. Trabajar sobre HTTP permite este tipo de comunicación entre todos los intermediarios en el camino. Si cumple con las especificaciones HTTP, hay muchas ventajas e incluso puede aumentar la seguridad de la API.

Capas de APi entre cliente servidor

James muestra las muchas capas entre el servidor y el cliente final. Como él dice, ¡hay mucho que poner en práctica!

Lea también: Una versión pragmática de los anti-patrones REST

Recientemente en el blog sopesamos los pros y los contras de adoptar hipermedia y enumeramos herramientas para ayudar en ese proceso. En su presentación, James agregó otra razón para considerar la hipermedia, y tiene que ver con los nuevos sistemas de comunicación.

Como vemos con ChatOps , las API ahora se utilizan para insertar herramientas en la conversación. Como dice James, "las API ahora se encuentran con las personas que necesitan hacer las cosas". Principalmente, está discutiendo cómo los canales de mensajería como Slack están extendiendo los flujos de trabajo a nuevos entornos. Ahora, las personas pueden tomar decisiones comerciales críticas en la aplicación de chat que elijan.

Hypermedia podría ayudar a personalizar el contenido para estos nuevos entornos mientras conserva la UX en todos los ámbitos. Al incluir URL únicas dentro de un paquete de respuesta, las API de hipermedia pueden indicar a los clientes qué capacidades son posibles y en qué escenarios. Los enlaces de hipermedia podrían reflejar inmediatamente los nuevos permisos de usuario, por ejemplo, sin interrumpir los cambios en el lado del cliente. James ve los hipermedia como una forma de que las API respondan a las plataformas de próxima generación y a los nuevos problemas que puedan surgir.

Herramientas relacionadas para facilitar el cumplimiento de HATEOAS

Webhooks y más

Si está familiarizado con los webhooks , probablemente esté familiarizado con Zapier y GitHub. El webhook de Github informa a los usuarios cada vez que un desarrollador emite un nuevo compromiso, revolucionando la forma en que se produce el software, pero también abriendo un mercado en torno a las canalizaciones de CD / CI. Zapier tiene su propio REST Hook estilo suscripción diseñado para reducir el sondeo.

También hay eventos enviados por el servidor, lo que nos permite transmitir eventos al cliente, transmisión de mensajes y más. Por ejemplo, James menciona Kafka, una solución de almacenamiento basada en registros que utiliza estos estilos de comunicación para transmitir mensajes a las partes interesadas dentro de una organización.

Los webhooks y estilos similares parecen adecuados para arquitecturas impulsadas por eventos : entornos asincrónicos donde una acción en particular debe desencadenar otra acción.

Lea una comparación profunda de WebSockets, WebHooks, REST Hooks, Pub-Sub y SSE aquí

Entonces, ¿REST sigue siendo un estilo de API relevante?

En una palabra, SI . Sin embargo, hay mucho que poner en práctica cuando se trata del diseño de API: es más que el servidor y el cliente lo que consume la API. James nos recuerda que debemos "pensar más allá de la computadora portátil" y nos deja con 5 conclusiones importantes:

  1.  En primer lugar, debemos comprender el problema empresarial y no privilegiar las tendencias tecnológicas por encima de los objetivos empresariales.
  2. Infórmese mejor sobre HTTP para reducir la dependencia de los marcos. Comprenda HTTP más allá de ese ciclo de vida CRUD y no use algo para lo que HTTP ya ha resuelto.
  3. Desarrolle los marcos que ya usa.
  4. Piense más allá de la computadora portátil: ¡hay mucho más que poner en práctica en el diseño de API!
  5. Al comparar estilos de API, deje de usar "vs." Más bien, adopte "&" para ver cómo cada estilo puede encajar en escenarios matizados o complementarse entre sí.

Claro, entre GraphQL, gRPC, REST y otros estilos de API, hay muchas formas de hacer que algo funcione rápidamente. Pero, considerar la administración, escalabilidad y longevidad de un servicio puede influir en la decisión que tome.

James nos recuerda que desde el punto de vista de la seguridad, cuanta más semántica se involucre, más áreas de superficie habrá que cubrir. Por último, y quizás lo más importante, el estilo de API elegido debe adaptarse a la personalidad de desarrollador a la que está atendiendo su servicio: ¡sus usuarios son su guía!

Para aquellos de ustedes al principio de su viaje hacia la API, buena suerte con su elección inicial de estilo de API. Veteranos de API: ¡dejen sus comentarios a continuación sobre lo que han aprendido para ayudar a otros!

Publicar un comentario

0 Comentarios