Header Ads Widget

Ticker

6/recent/ticker-posts

Cuándo usar qué: REST, GraphQL, Webhooks y gRPC


Con todo el amor y las proclamas sobre REST, a veces podemos olvidar que es simplemente una de las muchas opciones. REST es un muy buen estándar para una amplia variedad de API, pero existen otros estilos de diseño de API para escenarios más matizados.

Para ayudar a los desarrolladores de API a entender qué estilo de diseño de API usar y para qué situación, veamos REST dentro del contexto de otras tres opciones: gRPC , GraphQL y Webhooks . Ofreceremos ejemplos del mundo real de REST, GraphQL, gRPC y Webhooks en la práctica, y analizaremos sus fortalezas y debilidades para resaltar qué hace que cada opción sea una buena elección.

DESCANSO

REST es probablemente el elemento más conocido de este artículo, ya que se ha vuelto muy común entre las API web. REST como concepto fue definido por primera vez por Roy Fielding en su tesis doctoral en el año 2000. Él sentó las bases para un sistema arquitectónico definido por un conjunto de restricciones para los servicios web, utilizando un espíritu de diseño sin estado y un enfoque estandarizado para la construcción web. API.

REST, por su propia naturaleza, no tiene estado y está construido de tal manera que cualquier servicio web que cumpla con REST puede interactuar sin estado con representaciones de recursos textuales. Estas operaciones generalmente se definen utilizando GET, POST, PUT y otras metodologías HTTP como una cuestión de interacciones estandarizadas.

Una de las principales propiedades de REST es el hecho de que es rico en hipermedia . Hypermedia y REST dependen tan estrechamente, de hecho, que Roy Fielding ha declarado que las API técnicamente no son RESTful si no admiten hipermedia. En última instancia, esto significa que en una API REST, el cliente y el servidor están débilmente acoplados , lo que otorga a los clientes y servidores una gran libertad en la manipulación de recursos. Debido a esto, se habilitan y admiten la iteración rápida, la evolución del servidor, la elasticidad de la provisión de recursos y otros elementos similares.

REST admite mucho más de lo que veremos aquí, pero con una arquitectura en capas , almacenamiento en caché eficiente y alta escalabilidad , REST es una solución altamente detectable y altamente transformable para una multitud de problemas y limitaciones. El valor de tener una verborrea HTTP estandarizada es difícil de subestimar, proporcionando contexto al usuario final y estandarizando la mayoría de las interacciones. En total, REST es una solución muy eficiente, eficaz y poderosa para la industria moderna de API de microservicios.

Más sobre REST: ¿REST sigue siendo un estilo de API relevante?

Ejemplo del mundo real: PayPal

Un ejemplo de este tipo de API es la API REST de PayPal . PayPal tiene una función empresarial central sólida: proporcionar los sistemas integrados para el procesamiento de pagos. En consecuencia, sus API deben facilitar esto. Los recursos deben ser fácilmente identificables, las llamadas deben entenderse con y sin contexto y, lo que es más importante, se debe admitir una variedad de medios para manejar de manera efectiva una amplia gama de tipos y metodologías de pago.

Con este fin, la API de PayPal está diseñada para ser fácil de entender y de numera una variedad de actividades dentro de la API:

curl -v -integrar. Mire este ejemplo, tomado de su documentación, en el que una llamada eX GET https://api.sandbox.paypal.com/v1/activities/activities?start_time=2012-01-01T00:00:01.000Z&end_time=2014-10-01T23:59:59.999Z&page_size=10 \
-H "Content-Type: application/json" \
-H "Authorization: Bearer Access-Token"

Aquí, podemos ver las características de una implementación RESTful efectiva. Podemos ver una forma de verborrea HTTP estándar en GET haciendo exactamente lo que debería hacer GET: recuperar un recurso. El URI en este caso está bien definido como "actividades" y permite la especificación de una zona horaria y restricciones de solicitud en línea para el tamaño de la página. Además, la declaración está en un formato específico, conocido y compatible con hipermedia. Esto es REST en pocas palabras, y es un ejemplo de un caso de uso en el que un sistema ligero y sin estado es exactamente lo que se necesita para entregar los recursos al cliente final.

gRPC

Si bien REST es decididamente moderno, gRPC es en realidad una nueva versión de un enfoque antiguo conocido como RPC o llamada a procedimiento remoto. RPC es un método para ejecutar un procedimiento en un servidor remoto, algo parecido a ejecutar un programa en la computadora de un amigo a millas de su estación de trabajo. Esto tiene sus propios beneficios e inconvenientes: estos mismos inconvenientes fueron clave en el desarrollo y la implementación de REST, de hecho, junto con otros problemas inherentes a sistemas como SOAP.

Una diferencia clave entre gRPC y REST es la forma en que RPC define su negociación de contrato. Mientras que REST define sus interacciones a través de términos estandarizados en sus solicitudes, RPC funciona sobre una idea de contratos, en los que la negociación está definida y restringida por la relación cliente-servidor en lugar de la propia arquitectura. RPC otorga gran parte del poder (y responsabilidad) al cliente para la ejecución, mientras descarga gran parte del manejo y el cálculo al servidor remoto que aloja el recurso.

Por esta razón, RPC es muy popular para dispositivos IoT y otras soluciones que requieren comunicaciones contratadas personalizadas para dispositivos de bajo consumo. A menudo se considera que REST requiere recursos en exceso, mientras que RPC se puede utilizar incluso en situaciones de consumo de energía extremadamente bajo . gRPC es una evolución adicional en el concepto de RPC y agrega una amplia gama de características.

La característica más importante agregada por gRPC es el concepto de protobufs . Los protobufs son sistemas neutrales en cuanto al lenguaje y la plataforma que se utilizan para serializar datos, lo que significa que estas comunicaciones se pueden serializar y comunicar de manera eficaz. Además, gRPC tiene un sistema de autenticación muy eficaz y potente que utiliza SSL / TLS a través del sistema basado en tokens de Google. Por último, gRPC también es de código abierto , lo que significa que el sistema puede ser auditado, iterado, bifurcado y más.

Más sobre gRPC: Exploración del marco de gRPC para crear microservicios

API de ejemplo: Google Cloud, Bugsnag

Es difícil demostrar gRPC en la naturaleza; esto se debe en gran parte al hecho de que, de acuerdo con la propia documentación de gRPC, gRPC se usa generalmente en la "última milla de la informática". En otras palabras, gRPC suele ser el sistema final que impulsa y facilita la comunicación entre distintos servicios y API.

No obstante, la documentación de gRPC cita que, debido a su transportabilidad, gRPC se usa dentro del espacio de la computación móvil, así como un sistema intermediario y de procesamiento de datos de la API de Google Cloud BigTable Client , la API de Google Cloud PubSub y Google Cloud. API de voz . Esto tiene sentido, ya que el uso de mecanismos de transporte estándar y la carga de datos relativamente ágil que ofrece gRPC se pueden utilizar mejor para comunicaciones optimizadas, activas y repetitivas.

Otro ejemplo de gRPC en producción se puede encontrar con Bugsnag , un servicio de monitoreo de estabilidad. El equipo de ingeniería de Bugsnag encontró que el proceso de diseño inicial era más sencillo que construir RESTfully. Sin embargo, finalmente descubrieron que "la barrera de entrada para desarrollar y probar gRPC era bastante alta", debido a la falta de tutoriales y mejores prácticas . En general, las mejoras de latencia y la reducción de los costos de transporte hicieron que el uso de gRPC fuera un gran éxito para Bugsnag.

GraphQL

Logotipo de GraphQL

El enfoque de GraphQL a la idea de las relaciones cliente-servidor es único entre estas opciones, y es algo así como una inversión de la relación tradicional. Con GraphQL, el cliente determina qué datos quiere, cómo los quiere y en qué formato los quiere. Esto es una inversión del dictado clásico del servidor al cliente, y permite una gran cantidad de funcionalidad extendida. GraphQL es marcadamente diferente de REST, que es más una arquitectura que cualquier otra cosa, y de RPC, en el que el contrato es negociado por el cliente y el servidor pero definido en gran medida por los propios recursos.

Cabe señalar que una gran ventaja de GraphQL es el hecho de que, de forma predeterminada, normalmente entrega la solicitud más pequeña posible. REST, por otro lado, generalmente envía todo lo que tiene todo a la vez de forma predeterminada; en otras palabras, la solicitud más completa. Debido a esto, GraphQL puede ser más útil en casos de uso específicos donde un tipo de datos necesario está bien definido y se prefiere un paquete con pocos datos.

Dicho esto, los beneficios de GraphQL a menudo están algo sobrevendidos. La idea de que nunca es necesario realizar una versión se deriva de la desaprobación de campos y su sustitución por otros nuevos, que es de lo que se ocupa la evolución de REST. Por lo tanto, no debe pensar en GraphQL como "mejor" que REST o el "siguiente paso", como suele enmarcarse, sino más bien como una opción alternativa para una "nueva relación entre el cliente y los datos".

API de ejemplo: GitHub

Se puede encontrar un ejemplo del uso de GraphQL en la API GraphQL de GitHub API . Si bien la API RESTful inicial era poderosa e hizo lo que se solicitó, el equipo de GitHub descubrió que la API REST era inflexible. Hablando sobre el problema, el equipo dijo que las respuestas de la API "enviaron simultáneamente demasiados datos y no incluyeron los datos que los consumidores necesitaban", que es el punto de dolor clásico que causó el desarrollo de GraphQL en primer lugar.

En consecuencia, GitHub necesitaba una forma de entregar su contenido a los solicitantes sin requerir múltiples llamadas complejas y distintas. Necesitaban permitir a los usuarios transformar sus solicitudes, indicando qué necesitaban exactamente. Y lo más importante, necesitaban que la API aún fuera capaz de manejar las solicitudes básicas que la mayor parte de su API REST ya manejaba de manera eficiente. Con ese fin, Github agregó soporte para GraphQL, entregando estas funcionalidades clave.

Webhooks

Si bien GraphQL es una opción para extender una API, y gRPC es una reelaboración de un enfoque clásico, los Webhooks son un enfoque completamente diferente para la provisión de recursos que todo lo discutido aquí. Un Webhook es relativamente simple; en pocas palabras, es un HTTP POST que se activa cuando ocurre un evento.

Esta es una inversión de la relación clásica cliente-servidor: en el enfoque clásico, el cliente solicita datos del servidor y el servidor luego proporciona esos datos para el cliente. Bajo el paradigma de Webhook , el servidor actualiza un recurso aprovisionado y luego se envía automáticamente al cliente como una actualización. El servidor envía estos datos. Por lo tanto, el cliente no se convierte en un solicitante, sino en un receptor pasivo.

En última instancia, esta inversión se puede utilizar para facilitar una gran cantidad de comunicación que de otro modo requeriría solicitudes más complejas y sondeos constantes en el servidor remoto. Simplemente recibiendo el recurso sin solicitarlo directamente, puede actualizar bases de código remotas, distribuir recursos fácilmente e incluso integrarse en sistemas existentes para actualizar los puntos finales y otros datos relacionados con la API propiamente dicha.

Relacionado: WebHooks vs WebSub: ¿Cuál es mejor para la transmisión de eventos en tiempo real?

API de ejemplo: Foursquare (y SendGrid)

Los webhooks son una oferta relativamente simple y efectiva y, por lo tanto, su implementación es igualmente simple y efectiva. El método Foursquare de usar un webhook es esencialmente un flujo en el que el usuario "se registra", lo que solicita a un webhook que envíe contenido actualizado a otros sistemas y portales. De esta manera, el usuario puede interactuar directamente con la ubicación que está visitando mientras alerta a otros sobre la naturaleza de su relación con la ubicación a través de una analogía cliente-recurso.

A medida que avanza en los webhooks como implementación, a menudo verá integraciones más complejas. Por ejemplo, SendGrid usa webhooks para enviar actualizaciones de datos de eventos a los clientes suscritos, alertándolos sobre cambios en una gran cantidad de variables. SendGrid incluso implementa un método de webhook híbrido para analizar correos electrónicos .

Comparación de casos de uso para REST, GraphQL, Webhooks y gRPC

Como puede ver claramente, ninguna de estas opciones es realmente "mejor" que las demás, sino que encaja en escenarios de interacción únicos. Podemos resumir estos casos de uso de la siguiente manera:

  • REST : una arquitectura sin estado para la transferencia de datos que depende de hipermedia . REST puede unir una amplia gama de recursos que se pueden solicitar en una variedad de formatos para diferentes propósitos. REST se ocupa fundamentalmente de la gestión de recursos sin estado, por lo que es mejor utilizarlo en tales situaciones. Los sistemas que requieren una iteración rápida y una verborrea HTTP estandarizada encontrarán que REST se adapta mejor a sus propósitos.
  • gRPC : un sistema ágil y ligero para solicitar datos . gRPC, por otro lado, se usa mejor cuando un sistema requiere una cantidad determinada de datos o procesamiento de forma rutinaria, y en el que el solicitante tiene poca energía o está celoso de los recursos. El IoT es un gran ejemplo de esto.
  • GraphQL : un enfoque en el que el usuario define los datos esperados y el formato de esos datos . GraphQL es de Facebook, y ese pedigrí demuestra bien su caso de uso: situaciones en las que el solicitante necesita los datos en un formato específico para un uso específico. En esos casos, esos formatos de datos y las relaciones entre ellos son de vital importancia, y ninguna otra solución proporciona el mismo nivel de suministro de datos interconectados.
  • Webhooks : las actualizaciones de datos se entregarán automáticamente, en lugar de solicitarse . Finalmente, los Webhooks se utilizan mejor cuando la API en cuestión actualiza principalmente a los clientes. Si bien dichas API también pueden tener otras funciones, incluso RESTful, el uso principal de un microservicio de Webhook debe ser actualizar clientes y proporcionar datos actualizados y aprovisionados tras la creación del nuevo recurso actualizado.

Elegir entre estas opciones específicas es realmente una cuestión de alinear las funciones de su negocio con el enfoque apropiado y asegurarse de que los sistemas implementados respondan dentro de los parámetros dados.

Conclusión

La elección de un enfoque de diseño es quizás la decisión más importante que se toma en el desarrollo inicial de la API. Estructura la API y afecta la forma en que el usuario final interactuará con los recursos detrás de la propia API. En otras palabras, esta no es solo una elección de enfoque para el desarrollador, es una elección de cómo va a establecer su relación con sus consumidores.

En última instancia, la elección de la solución que elija se reduce a lo que se adapte a su caso de uso particular. Cada solución tiene un propósito muy específico y, como tal, no es justo decir que una es mejor que la otra. Sin embargo, es más exacto decir que algunas son mejores para hacer sus funciones básicas que las otras soluciones, como el caso de muchas soluciones RESTful que intentan reflejar la funcionalidad RPC.

Solo usted puede determinar qué solución se adapta mejor a su código base. Por lo tanto, investigue y elija el enfoque correcto desde el principio para obtener importantes beneficios. Su código será más sencillo, más receptivo y adaptado a la situación actual.

 

Publicar un comentario

0 Comentarios