Header Ads Widget

Ticker

6/recent/ticker-posts

¿REST sigue siendo un buen estilo de diseño de API para usar?

 Entrevistamos a tres expertos sobre el estado del diseño de API REST

La transferencia de estado representacional, o REST, es un patrón arquitectónico dominante. Desde que Roy Fielding lo concibió en 2000, REST se ha convertido en el método predominante para diseñar API web robustas. Sin embargo, con la llegada de nuevas demandas de aplicaciones, algunos se preguntan si REST es adecuado para cada caso de uso.

Los estilos arquitectónicos alternativos y las nuevas herramientas parecen cuestionar: ¿REST sigue siendo un buen estilo de diseño para usar ? Para ayudar a responder esa pregunta, entrevistamos a tres expertos en el campo: Thibault Ducret , ingeniero de backend senior en Delair , Henrik Stene , gerente de tecnología en Aboveit , y Zdenek “Z” Nemec , fundador de Good API Consulting .

Todos los entrevistados hablarán en la Cumbre de la Plataforma 2019 . ¡Esperamos que te unas a nosotros este octubre! Los boletos todavía están disponibles aquí .

¿REST sigue siendo un buen estilo de diseño para usar?

En resumen, todos los panelistas están de acuerdo en que REST sigue siendo un estilo relevante y útil. Una razón es que REST fue diseñado para durar .

"Si está creando un producto API que será consumido por clientes sobre los que no tiene control, debería escalar indefinidamente y durar décadas", dijo Z. "Para eso, no hay mejor estilo que REST".

Debido a su popularidad, muchos desarrolladores ya se sienten cómodos con REST. Existen amplias bibliotecas de cliente REST en la mayoría de los lenguajes de programación. Como señala Thibault, "los desarrolladores necesitan información mínima para utilizar una API RESTful en su aplicación".

Todos los panelistas están de acuerdo en que REST brinda beneficios de usabilidad y es una base de calidad para el diseño de API. Sin embargo, todos reconocen que los requisitos de las aplicaciones individuales pueden requerir otras tecnologías. Como señala Thibault, "la adopción [fácil] no es el único criterio para elegir el diseño de su API".
"Debemos considerar las necesidades y requisitos de cada aplicación o punto final caso por caso", dijo Henrik. "Creo que las API REST pueden proporcionar un excelente punto de partida para la mayoría de las API, pero existen algunas buenas razones para complementar REST con otras tecnologías".

Para Z, la cuestión de si utilizar o no REST se reduce a la naturaleza del producto. “Veo estilos de API como REST, transmisión o consulta en función del ajuste del mercado de productos de la API”, dijo Z.

Thibault agrega que REST a menudo se malinterpreta. Casi todas las API "RESTful" carecen de un componente clave: hipermedia. Entonces, técnicamente, nunca ingresamos al paradigma REST porque la mayoría de las API ni siquiera son REST en absoluto.

¿Para qué casos de uso REST no es una buena opción?

REST es aplicable para muchos casos de uso, pero deja lagunas. Como dice Henrik, "realmente no creo que REST no sea una buena opción para ninguno de los casos de uso tradicionales, pero hay otras tecnologías que ayudarán a 'sobrecargar' las API y mejorarlas".

Thibault observa tres áreas distintas en las que REST no es una buena opción: mensajería , microservicios internos rendimiento con GraphQL y gRPC.

Como describe Thibault, las API de estilo de mensajería no son adecuadas para REST porque obligan a los usuarios a realizar un sondeo constante un dolor de cabeza y una pérdida de rendimiento. “Preferiría diseñar la arquitectura en torno al patrón de publicación-suscripción e implementarla a través del protocolo de conexión web”, dijo Thibault. Asimismo, Z argumenta que REST no es aplicable para API impulsadas o impulsadas por eventos.

Otro caso en el que REST es insuficiente es cuando separa un monolito y tiene microservicios que deben comunicarse entre sí. En este escenario, "puede tener la tentación de reemplazar las llamadas a funciones de la aplicación monolítica con solicitudes API REST síncronas", dijo Thibault. Esto crea una serie de solicitudes de API secuenciales, esencialmente perpetuando el monolito .

Z también reconoce que los servicios internos llenos de perros pueden beneficiarse de estilos alternativos de diseño de API. “Uno de los casos de uso en los que puede usar otro estilo de API es si está hablando solo”, dijo Z. “Es decir, si está creando un Backend para Frontend , usted es el único usuario de esa API y puede coordinar las implementaciones de ambos componentes ".

Por último, Thibault cree que REST no se adapta bien a escenarios en los que el alto rendimiento es fundamental para los usuarios. En REST, los desarrolladores no pueden llamar a varios recursos con una sola llamada a la API o recuperar solo las propiedades que requiere el cliente. Para estos escenarios, Thibault reconoce que GraphQL es una opción más elegante. Alternativamente, existen otras opciones, como agregar un parámetro de consulta de campos o usar una carga útil optimizada (pero menos legible) como gRPC .

Lea también: Cuándo usar Qué: REST, GraphQL, Webhooks y gRPC

Llevando el diseño de API más allá de REST

Entonces, conociendo los inconvenientes de REST, ¿es inevitable que otros estilos de diseño lo reemplacen? La respuesta no es corta y seca.

Henrik reconoce que cada caso es único. Sin embargo, ve una clara tendencia. "Todos hemos observado un cambio en la industria con respecto a cómo se almacenan y comparten los datos", dijo Henrik. “Este cambio permite que brillen otras tecnologías”.

Thibault describe cómo la usabilidad fue un factor importante para salir del estilo de arquitectura REST en su empresa, Delair. “Muchas operaciones usaban el mismo punto final a pesar de ser diferentes”, dijo Thibault.

Para aumentar la usabilidad, Delair reemplazó este único punto final genérico '/ conjunto de datos' (PATCH) con puntos finales específicos:

  • /rename-dataset (ENVIAR)
  • /add-dataset-categories (ENVIAR)
  • /update-dataset-ingestion (ENVIAR)
  • /update-dataset-horizontal-srs (ENVIAR)
  • y más.

“Esta API es mucho más legible para el usuario y permite una implementación más simple para nuestro backend, dijo Thibault.

Los estilos técnicos son simplemente pautas y no siempre reflejan la mejor manera de generar valor. Las opciones de diseño de API se reducen a saber qué es lo mejor para el equipo, el consumidor desarrollador.

"Cuando tiene que modificar su API para que coincida con el paradigma REST, puede ser una pista de que podría encontrar otra forma de diseñarlo", dijo Thibault.
"REST es solo una herramienta", reiteró Z. "Los diseñadores deben centrarse primero en el diseño y la comunicación de sus modelos de dominio y acciones y solo entonces en los matices de un estilo de API en particular".

¿Los entornos asincrónicos están interrumpiendo las expectativas típicas de REST?

Como hemos cubierto antes, están surgiendo nuevas API de estilo de transmisión asíncrona. Estos servicios impulsados ​​por eventos involucran protocolos alternativos e incluso tienen nuevas comunidades y estándares como la API Async . Pero, ¿afecta esto al diseño de REST?

Henrik señala su aparición y potencial para desarrollar la norma REST actual. “Las API asincrónicas se están volviendo más populares debido a que los consumidores de API tienen expectativas de disponibilidad de datos diferentes a las que tenían antes”, dijo Henrik.

Thibault también ve un problema de escalabilidad para los asincrónicos si se atasca en un paradigma REST:

“Cuando necesita proporcionar notificación de eventos para varios servicios, REST alcanza su límite (así como todas las API HTTP síncronas). La notificación de un servicio al final de un proceso se puede hacer con una devolución de llamada, pero ¿qué pasa con la notificación de diez servicios? ¿Cuánto tiempo tomará si todas estas devoluciones de llamada se ejecutan secuencialmente? ¿Qué sucede si un nuevo servicio también necesita recibir la notificación? El uso de REST y devoluciones de llamada claramente no es escalable para este propósito ".

Thibault describe cómo Delair usa un clúster de Apache Kafka para un agente de mensajes. Esto permite que los servicios se suscriban a una cola de mensajes para procesar solicitudes de forma asincrónica.

Según Z, los requisitos asincrónicos pueden complementar una oferta REST, en lugar de interrumpirla. En términos de herramientas, además de Kafka, destaca WebSub como una opción viable.

"WebSub es un protocolo asombroso que es eficiente, soluciona los problemas con los webhooks y funciona bien con REST e hipermedia y, como tal, agrega sin problemas la funcionalidad de" empuje "a las API REST", dijo Z. "Como tal, agrega sin problemas la Funcionalidad de "inserción" en las API REST ".

Principales conclusiones

Bueno, ahí lo tienes. El estado del diseño de API REST según algunos de los pensadores más brillantes de la industria. Para resumir:

  • REST sigue siendo relevante . REST sigue siendo un buen estilo para la mayoría de las aplicaciones. Tiene una comunidad de herramientas activa y los desarrolladores generalmente se sienten cómodos con ella.
  • Sin embargo, REST tiene deficiencias . REST no proporciona patrones de recuperación de datos flexibles como GraphQL. REST no se adapta bien a escenarios impulsados ​​por eventos de gran volumen.
  • Existen otras opciones . Por ejemplo, GraphQL o gRPC. Kafka o WebSub pueden agregar funcionalidad de inserción a las API REST. Los microservicios internos o backend para front-end pueden beneficiarse de estilos alternativos de API o agentes de mensajes.
  • Los negocios son lo primero . No dejes que el estilo te imponga demasiado. Desarrolle su tecnología para que coincida con sus modelos de comunicación y negocios ideales, no al revés.
  • Developer Experience (DX) es independiente del estilo . Se puede lograr una experiencia de desarrollador de calidad utilizando una amplia variedad de estilos de API.

Explore los estilos de diseño de API en Platform Summit

Los asistentes a la Cumbre de la Plataforma tienen una oportunidad única de aventurarse en conocimientos más profundos sobre los estilos de diseño de API. Esto es lo que nuestros panelistas tienen que decir sobre sus próximas charlas:

  • Asista a la sesión de Henrik Stene Creación de API más allá de REST . Esta es una “charla de experiencias” donde intentaré explicar cómo terminamos con las combinaciones de API que hicimos en Entur (el cliente), y qué teníamos que considerar antes de implementar las API.
  • Asista a la sesión de Thibault Ducret Ya no estamos RESTful ... y está bien
    , presentaré los problemas que tuvimos en Delair al crear nuestras API RESTful. Lo guiaré a través de ejemplos del mundo real (¡que involucran drones!) Y detallaré las formas en que solucionamos los problemas. Obtendrá una buena descripción general de nuestro estilo de API y los beneficios desde la implementación.
  • Asista a la sesión de Zdenek “Z” Nemec What API: Your Guide to API Styles . Primero, espero explicar este enfoque basado en productos para la selección del estilo de API. Nosotros, como ingenieros, tendemos a ver todo como clavos una vez que tenemos el martillo en la forma de un cierto estilo API. Con este conocimiento, me gustaría proporcionar un marco para tomar decisiones sobre qué estilo de API usar para un producto determinado.

Publicar un comentario

0 Comentarios