Breaking

Post Top Ad

Your Ad Spot

sábado, 25 de enero de 2020

REST vs Streaming APIs: cómo difieren

DESCANSO vs JABÓN. REST vs GraphQL. JSON vs XML. Hay muchas dicotomías en el mundo del diseño de API . Parece que para cada elección arquitectónica existe una solución opuesta diseñada específicamente para una aplicación específica. Podemos ver esto en cuestiones como la apatridia y la apatridia , así como en opciones funcionales como SOAP y REST .
Hoy, veremos una de esas dicotomías: las  API REST y Streaming . Estas dos opciones son fundamentalmente diferentes en una variedad de formas, entre las cuales se encuentra su relación esencial entre el cliente y el servidor . Por esta razón, las arquitecturas son comparables, y las soluciones presentes en cada campo son objeto de mayor discusión.
Tenga en cuenta que gran parte de esta pieza utilizará generalidades y seguramente habrá casos extremos. Considere esto una descripción general de los casos de uso estándar detrás de las API REST y Streaming , así como las arquitecturas, enfoques y naturalezas estándar que uno esperaría de cada uno.

Comparación de las API REST y Streaming

DESCANSO

Las API REST pueden considerarse como una conversación en curso.
A pesar del número de defensores de las llamadas soluciones "REST-like", REST está realmente bien definido en restricciones : su creador, Roy Fielding, ha establecido varias restricciones clave que conforman una API REST .
Primero, una API REST funciona en una arquitectura cliente-servidor . Por diseño, las API RESTful separan las preocupaciones del cliente y del servidor, lo que permite que cada una evolucione independientemente una de la otra. Esto también significa que el flujo típico de información en dicha relación es fundamentalmente un paradigma de solicitud / respuesta: un cliente solicita algo y el servidor responde con la información solicitada.
En segundo lugar, y principal para el nombre en sí (REST es la abreviatura de Transferencia de estado representacional), las API RESTful no tienen estado . La API en sí no contiene ningún contexto de cliente en el servidor más allá de lo relevante para la solicitud inmediata y la información necesaria para autenticar al cliente. Si bien es técnicamente cierto que este estado se puede almacenar en otro lugar, como en una base de datos, y por lo tanto no se almacenaría "técnicamente" en la API en sí, eso no es realmente "estado" tanto como es "contexto almacenado".
Hablando de contexto almacenado, las API REST son almacenables en caché . Pueden almacenar datos que han sido solicitados previamente y luego servir esos datos a pedido. En teoría, también deberían poder ampliar temporalmente sus capacidades mediante el uso de extensiones ejecutables; sin embargo, esto es completamente opcional.
Finalmente, las API REST deberían estar algo ofuscadas para el usuario final, con un sistema API en capas de intermediarios y servidores primarios que puedan llevar a cabo la instrucción sin exponer su posición en la jerarquía al usuario final. Esto es en gran medida un requisito para proporcionar escalabilidad y equilibrio de carga , aunque hay beneficios adicionales para este enfoque, a saber, el aumento de la seguridad al reducir la visibilidad de los vectores de ataque, la capacidad de distribuir y compartir información almacenada en caché sobre cachés geográficamente diferentes y redundancia en la función del servidor para garantizar un tiempo de actividad óptimo.
  • Justificación : REST es, por su diseño, sin estado, altamente escalable y flexible en resultados. Está diseñado alrededor del modelo de solicitud-respuesta. Por esta razón, REST es más útil en entornos donde el cliente puede solicitar una amplia gama de llamadas, donde el servidor puede responder con datos variados y diferentes, y donde el hipermedia es compatible con arquitecturas flexibles, escalables y modificables.
  • Ejemplos : Algunos buenos ejemplos de REST incluyen api.video (que proporciona la entrega de videos RESTful) y las API de viajes Skyscanner (que proporcionan herramientas para comparar precios de vuelos, automóviles y hoteles).

Transmisión

Las API de transmisión, por otro lado, envían actualizaciones al cliente cuando se producen eventos.
Las API de transmisión son casi exactamente opuestas al espíritu REST. En su estado más básico, las API de Streaming invierten la naturaleza conversacional de REST , donde se realiza una solicitud y se da una respuesta, y en su lugar el servidor envía información a un cliente cuando una actualización está lista. Si bien el cliente puede, en teoría, solicitar una actualización, el servidor de transmisión debe evitarlo con las actualizaciones listas.
Esta es una inversión total del paradigma REST, mientras que las API REST no tienen estado, las API de transmisión tienen, por su propia naturaleza, estado . Sin almacenar el estado de alguna forma, la API de Streaming no puede contextualizar adecuadamente la relación de datos con el cliente solicitante. En otras palabras, los clientes suelen abrir conexiones persistentes con el servidor de transmisión en cuestión. Si bien esta conexión ciertamente tiene una vida útil limitada, es durante esta conexión que se entrega el contenido enviado.
Si las API de REST son una conversación, las API de Streaming son más parecidas a ver una película en una sala de cine; si REST son dos personas hablando, una API de Streaming es una persona que compra un boleto de cine, se sienta en un teatro y recibe pasivamente la película.
Una diferencia importante que debe mencionarse es que las API de Streaming tienen mucha menos flexibilidad en el tipo de contenido en comparación con REST. Debido a que REST es un modelo de solicitud / respuesta, la solicitud inicial contiene toda la información requerida para llevar a cabo esa solicitud. Por lo tanto, cuando se realiza una solicitud, en algunas aplicaciones (como GraphQL), el formato o tipo de contenido puede establecerse como una variable compatible esperada.
Las API de transmisión, por otro lado, generalmente tienen un formato de respuesta estrictamente limitado. Aunque a veces puede solicitar un tipo diferente, está declarando esto por adelantado, no como parte de su solicitud y, a menudo, esto ni siquiera es compatible. En otras palabras, obtienes lo que proporciona el servidor.
  • Justificación : las API de transmisión admiten un caso de uso opuesto de REST. Se utilizan mejor cuando un cliente solicita datos únicos, conocidos y formateados de un servidor o servicio. Los datos se solicitan y procesan menos para una respuesta de lo que se solicita a partir de datos ya generados, y como tal, la transmisión es más apropiada en un caso de uso donde la interacción es menos conversacional y es de naturaleza más informativa.
  • Ejemplos : Algunos ejemplos de API de Streaming incluyen la API de Twitter (PowerTrack, Volume y Replay que proporciona datos en tiempo real, metadatos de Tweet para ingesta y datos generalizados) y la API de Salesforce en tiempo real (que permite disparadores de eventos PushTopic y Data Capture) .

Diferencias arquitectónicas

Arquitectura de soporte REST

REST es fundamentalmente una relación de tipo solicitud / respuesta entre el cliente y el servidor. Se solicita algo, se hace algo y luego se envía algo a cambio. Este intercambio es una conversación ; por esta razón, la arquitectura REST generalmente está diseñada en torno a la idea de proporcionar micro soluciones altamente modulares para casos de uso determinados.
La arquitectura subyacente detrás de la totalidad de REST es el servidor web modular . Esto puede tomar la forma de servidores físicos o servidores virtuales, pero en última instancia, la idea de nodos que pueden girar rápidamente hacia abajo o hacia abajo es muy esencial para el panorama RESTful lleno de microservicios que domina la mayor parte del panorama REST empresarial.
Estos servidores también tienen un requisito muy específico: deben ser capaces de admitir tanto el ancho de banda de las solicitudes como el ancho de banda resultante de la salida personalizada requerida. Incluso con soluciones livianas, este sigue siendo un requisito fundamental del nodo del servidor REST: debe poder conversar .
Cabe señalar que gran parte de REST se basa en el transporte y la verborrea HTTP estándar Por esa razón, una gran cantidad de interacción RESTful será al menos compatible con, si no se guiará principalmente mediante, el estado HTTP y los códigos de error . Si bien esto no es exclusivo de REST, se han hecho muchas elecciones arquitectónicas para admitir el uso de estos códigos y hacer que activen ciertas acciones dentro de las implementaciones RESTful.

Arquitectura de soporte de transmisión

Las API de transmisión son una inversión del enfoque RESTful y, por esta razón, gran parte de la arquitectura subyacente difiere de lo que se requiere con REST. REST requiere una solicitud de gran ancho de banda y servidores orientados a la respuesta: las API de transmisión, por otro lado, utilizan agentes de eventos para gestionar esta interacción.
En un escenario de transmisión, no es una conversación y, por lo tanto, el hardware realmente no necesita soportar eso. Lo que el software debe admitir es un método simple para almacenar el estado de una conexión abierta o un solicitante a largo plazo, y luego enviar la misma información de forma global a cada grupo de usuarios.
Esto es muy diferente de REST, y como tal, gran parte del enfoque conceptual básico de los cambios de arquitectura en su propósito raíz. La escalabilidad ahora es menos una preocupación de admitir un mayor volumen de solicitudes y, en cambio, se trata principalmente de admitir grandes cantidades de cómputo para clientes actualizados y conexiones abiertas.
La transmisión sigue funcionando a través de los mismos métodos HTTP que REST, pero debido a sus interacciones controladas por eventos, la relación cambia el poder del cliente solicitante al servidor proveedor. Como tal, la visión del mundo "centrada en el cliente" de la estrategia de verborrea y solicitud debería revertirse, en lugar de cambiar "qué puedo solicitar del servidor" a "cómo es útil para mí el punto final en el servidor".

Conclusión

En resumen, las API REST y Streaming tienen pilas muy diferentes, y por una buena razón: admiten flujos de trabajo fundamentalmente diferentes para diferentes casos de uso. Esto significa que la arquitectura es diferente y en gran medida, construida para diferentes propósitos. Comprender estas diferencias puede ayudar a identificar un valor específico detrás de cada implementación, así como las funciones básicas subyacentes que hacen posible estos enfoques.
¿Qué piensas sobre la transmisión y las API RESTful? ¿Pueden funcionar las API RESTful en el espacio de transmisión? ¡Háganos saber en los comentarios a continuación!

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

Post Top Ad

Your Ad Spot

Páginas