Header Ads Widget

Ticker

6/recent/ticker-posts

REST vs API de transmisión: en qué se diferencian

 



DESCANSO vs JABÓN. REST vs GraphQL. JSON frente a 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 condición de estado , así como en opciones funcionales como SOAP y REST .

Hoy veremos una de esas dicotomías:  API REST y Streaming . Estas dos opciones son fundamentalmente diferentes en una variedad de formas, una de las cuales es la relación esencial entre el cliente y el servidor . Por esta razón, las arquitecturas son comparables y las soluciones presentes en cada campo merecen una discusión adicional.

Tenga en cuenta que gran parte de esta pieza utilizará generalidades y es probable que haya casos extremos. Considere esto como una descripción general de los casos de uso estándar detrás de REST y las API de transmisión , así como las arquitecturas, enfoques y naturalezas estándar que uno esperaría de cada uno.

Comparación de REST y API de transmisión

DESCANSO

Las API REST se pueden considerar como una conversación en curso.

A pesar del número de defensores de las llamadas soluciones "similares a REST", REST está realmente bien definido en cuanto a restricciones : su creador, Roy Fielding, ha establecido varias restricciones clave que componen 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 de información típico en tal 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 del nombre en sí (REST es la abreviatura de Representational State Transfer), 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 propia API, eso no es realmente "estado" tanto como "contexto almacenado".

Hablando de contexto almacenado, las API REST se pueden almacenar 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 sus capacidades temporalmente 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 instrucciones sin exponer su posición en la jerarquía al usuario final. Esto es en gran parte un requisito para proporcionar escalabilidad y equilibrio de carga , aunque hay beneficios adicionales para este enfoque, a saber, aumentos en la seguridad al reducir la visibilidad de los vectores de ataque, la capacidad de distribuir y compartir información almacenada en caché a través de cachés geolocalizados de manera diferente y redundancia. en función de servidor para garantizar un tiempo de actividad óptimo.

  • Justificación : REST es por su diseño sin estado, altamente escalable y flexible en la salida. Está diseñado en torno al 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 que se soporta requiere arquitecturas flexibles, escalables y cambiantes.
  • Ejemplos : algunos buenos ejemplos de REST incluyen api.video (que proporciona entrega de video RESTful) y las API de viaje de Skyscanner (que brindan 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 ocurren eventos.

Las API de transmisión son casi exactamente lo opuesto al espíritu REST. En su estado más básico, las API de transmisión 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 debería adelantarse a esto 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 son por su propia naturaleza con estado . Sin almacenar el estado de alguna forma, la API de transmisión 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 cuando se entrega el contenido enviado.

Si las API REST son una conversación, las API de transmisión son más parecidas a ver una película en una sala de cine; si REST son dos personas hablando, una API de transmisión es una persona que compra un boleto de cine, se sienta en un cine y recibe pasivamente la película.

Una diferencia importante que debe mencionarse es que las API de transmisión tienen mucha menos flexibilidad en el tipo de contenido que REST. Debido a que REST es un modelo de solicitud / respuesta, la solicitud inicial contiene toda la información necesaria para llevar a cabo esa solicitud. Por lo tanto, cuando se realiza una solicitud, en algunas aplicaciones (como GraphQL), el formato o el tipo de contenido se puede establecer como una variable admitida esperada.

Las API de transmisión, por otro lado, suelen tener un formato de respuesta estrictamente limitado. Aunque a veces puede solicitar un tipo diferente, lo indica por adelantado, no como parte de su solicitud y, a menudo, esto ni siquiera se admite en absoluto. En otras palabras, obtienes lo que proporciona el servidor.

  • Justificación : las API de transmisión admiten un caso de uso opuesto al de REST. Se utilizan mejor cuando un cliente solicita datos formateados, conocidos y únicos de un servidor o servicio. Los datos se solicitan y procesan menos para una respuesta de lo que se solicitan a partir de datos ya generados y, como tal, la transmisión es más apropiada en un caso de uso en el que la interacción es menos conversacional y de naturaleza más informativa.
  • Ejemplos : algunos ejemplos de API de transmisión incluyen la API de Twitter (PowerTrack, Volume y Replay que proporcionan datos en tiempo real, metadatos de Tweet para la ingesta y datos generalizados) y la API de Salesforce en tiempo real (que permite activar eventos PushTopic y Data Capture) .

Diferencias arquitectónicas

Arquitectura de soporte de REST

REST es fundamentalmente una relación de tipo solicitud / respuesta entre cliente y 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 se diseña en torno a la idea de proporcionar micro-soluciones altamente modulares para casos de uso dados.

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 arriba o hacia abajo es fundamental para el panorama de microservicios RESTful que domina la mayor parte del panorama REST empresarial.

Estos servidores también tienen un requisito muy específico: deben poder admitir tanto el ancho de banda de las solicitudes como el ancho de banda resultante de la salida personalizada requerida. Incluso con soluciones ligeras, 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 respaldada, si no guiada principalmente, por códigos de error y estado HTTP Si bien esto no es exclusivo de REST, se han realizado muchas elecciones de arquitectura 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 servidores orientados a respuestas y solicitudes de gran ancho de banda; las API de transmisión, por otro lado, utilizan agentes de eventos para administrar esta interacción.

En un escenario de transmisión, no es una conversación y, por lo tanto, el hardware realmente no necesita admitir eso. Lo que el software necesita admitir es un método simple de almacenar el estado de una conexión abierta o un solicitante a largo plazo y luego enviar la misma información globalmente a cada grupo de usuarios.

Esto es muy diferente de REST y, como tal, gran parte del enfoque conceptual básico de la arquitectura cambia 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 mayores cantidades de procesamiento para clientes actualizados y conexiones abiertas.

La transmisión sigue operando con los mismos métodos HTTP que REST, pero debido a sus interacciones impulsadas 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 verborrea y la estrategia de solicitud debe invertirse, en lugar de cambiar "qué puedo solicitar del servidor" a "cómo me resulta útil el punto final del 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 el valor específico detrás de cada implementación, así como las funciones básicas subyacentes que hacen posibles estos enfoques.

¿Qué opinas 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!

Publicar un comentario

0 Comentarios