Header Ads Widget

Ticker

6/recent/ticker-posts

La API que desafió a REST: instancias más comunes de API no RESTful y lo que realmente importa

 

Instancias más comunes de APIs unRESTful

El diseño RESTful es similar a la interfaz gráfica de usuario en las computadoras modernas: lo suficientemente ubicuo como para ser considerado la opción de facto, pero en la práctica, no necesariamente la única opción. Ciertamente, muchos consideran que REST es el rey de la colina, pero es un error pensar que es el único jugador en la ciudad.

De hecho, es más correcto afirmar que el diseño RESTful no es el más popular, sino simplemente el más público: hay un verdadero exceso de API que desafían los estándares REST y, de hecho, impulsan muchas de esas API REST exitosas.

Hoy, vamos a echar un vistazo a algunas de las instancias más comunes de APIs noRESTful, aislando qué es lo que hace que estas API y sistemas funcionen fuera del ámbito de las pautas RESTful. Analizaremos otras alternativas a REST y determinaremos qué tipo de estándares realmente importan al diseñar API web sólidas ...

Definición de REST

Antes de profundizar demasiado en este tema, definamos realmente qué es REST y cómo se aplica a las API. Este es un conocimiento elemental para muchos aficionados a las API, pero muchos se sorprenderían de cuántos términos y conceptos comunes a menudo se malinterpretan o se tergiversan en el uso común .

En definición seca, REST significa Representational State Transfer, y se enfoca en comunicaciones cliente-servidor sin estado, con mayor frecuencia a través de HTTP, como lo definió Roy Fielding en su innovadora disertación que originalmente definió REST . En el uso real, lo que REST normalmente significa es significativamente más complicado.

Para obtener más información, consulte nuestra comparación infográfica REST vs SOAP

En primer lugar, respecto a las llamadas realizadas por un cliente RESTful. RFC 7231 establece que "los métodos de solicitud se consideran" seguros "si su semántica definida es esencialmente de solo lectura".

La idempotencia es una bestia extraña, pero es fundamental tanto para la seguridad extendida como para la funcionalidad de una API RESTful. Para ser idempotente , varias solicitudes idénticas a una API deberían producir el mismo efecto que una sola solicitud. RESTAPITutorial define la indempotencia como "los clientes pueden hacer la misma llamada repetidamente mientras producen el mismo resultado". Por ejemplo, una API con una función de agregar carrito de compras no debe incluir una solicitud GET con un modificador de carrito, como a continuación:

http://nordicapis.com/addToCart?cart=1234&item=5678

Esta llamada agrega un elemento adicional en cada ejecución, que va en contra de las pautas de REST. Esta limitación de función es la misma en cualquier función, ya sea una solicitud de datos adicionales, una modificación de los datos almacenados del lado del servidor o el establecimiento de una causa para el servidor (es decir, el establecimiento de datos de parámetros de autenticación y autorización). Sin embargo, hay excepciones a la regla: para una API REST que funcione a través de HTTP, tenga en cuenta que DELETE no es seguro, pero es idempotente, y POST y PATCH son seguros, pero no siempre idempotentes.

Fielding dice que “las API REST no deberían depender de un solo protocolo de comunicación.“El objetivo de REST es establecer estados de aplicación dinámicos a través de un motor de estado impulsado por hipertexto para facilitar su uso y transferencia. Como Fielding describe , " si el motor del estado de la aplicación (y por lo tanto la API) no está siendo impulsado por hipertexto, entonces no puede ser RESTful y no puede ser una API REST".

Finalmente, y quizás lo más importante, el diseño RESTful debería depender de una especie de comunicación ciega entre el cliente y el proveedor. Los usuarios deben entrar en el proceso de comunicación y apretón de manos con un solo URI o colección de URI que luego presentan una lista de opciones generadas a través de las propiedades del servidor para su interacción. Básicamente, REST, a pesar de tener "estado" en su nombre, técnicamente no tiene estado : el servidor no almacena estados para la sesión del cliente en el lado del servidor, sino que confía en que el cliente almacene esos datos y los pase al servidor cuando sea necesario. .

Con todo esto en mente, ¿cuáles son algunos de los grandes casos de API que no tienen descanso ?

Datos complejos con Evernote

Un gran ejemplo de cuándo fallan los enfoques de diseño RESTful es en el conjunto de aplicaciones de productividad de Evernote. REST es excelente en lo que hace cuando maneja datos, pero hay una falla fundamental en cómo maneja transferencias de datos complejas.

Evernote es un ejemplo de API irresistible

La API de Evernote no está DESCANSO para manejar transferencias de datos complejas de manera más eficiente

Cada fragmento de datos en el enfoque RESTful está subrayado por los flujos de control de los servicios subyacentes y, debido a esto, las API RESTful a menudo enfrentan grandes cuellos de botella. El problema es tan extremo en grandes conjuntos de datos que algunos grupos, como el Laboratorio de Plataformas de Servicios de HP Labs en Singapur , han diseñado sistemas completos para restringir mejor el flujo de trabajo de datos.

Sin embargo, en lugar de reparar un agujero en el barco que se estaba hundiendo, Evernote se esforzó por crear una solución que no le permitiera descansar directamente en el código . Al depender de Apache Thrift, y no de HTTP como lo dictan las especificaciones de la API REST, las transferencias de datos son mucho, mucho más eficientes.

El uso de Thrift también abrió la API para manejar enlaces nativos, en lugar de procesar cada relación e interacción de código en cada cliente. No tener que preocuparse por analizar y clasificar el código elimina muchos de los errores en el nivel de interacción básico.

Lo más importante es que Evernote logró evitar muchos de los errores de compatibilidad que surgen al diseñar en un estado RESTful. Los clientes desarrollados hoy funcionarán con clientes de hace años, y en cinco años, estos clientes actuales funcionarán con esas revisiones futuras, sin ningún problema.

Contratos en SOAP

REST tampoco es el único jugador. SOAP, o Simple Object Access Protocol, es una alternativa a REST y, por su propia naturaleza, incompatible como operante. Si bien REST puede usar servicios web SOAP, SOAP como protocolo no puede definirse como RESTful.

La mejor manera de pensar en la diferencia entre SOAP y REST es pensar en términos de intercambio de correo. SOAP es como un sobre, mientras que REST es como una postal. Mientras que REST es sencillo, limpio y eficaz, SOAP tiene muchos más gastos generales. Por otro lado, puede caber mucho más dentro de un sobre que dentro de una postal.

Lo que esto significa funcionalmente es que, a pesar de ser más pesado con una mayor sobrecarga, SOAP es a menudo una opción mucho más segura, especialmente cuando se deben dictar contratos e interacciones formales.

Un buen ejemplo de donde SOAP tiene sentido sobre REST es la API de PayPal SOAP . Debido a que el ecosistema de PayPal depende completamente de la comunicación contractual con un esquema de seguridad específico, una solución SOAP tiene más sentido que una RESTful. Si bien muchos de los datos se registran con nombres de usuario y contraseñas, así como con ID de proceso e información de transacción, esto es en realidad un beneficio, ya que este proceso registra transacciones e interacciones en identificadores únicos.

Como nota al margen, la API de PayPal hace algo increíblemente útil que muchas API evitan. La API de PayPal, por diseño, asume que los datos que se procesan están en Unicode UTF-8 y devuelve datos en ese formato. Esto cubre las interacciones y las transacciones nacionales e internacionales, y es vital para prevenir errores y otros problemas en la API.

Dicho esto, la API de PayPal también es un gran ejemplo de cómo REST puede ser "pirateado" para tener casi los mismos beneficios. El desarrollador considera que las API de SOAP son heredadas , y algunos de los conjuntos de funciones se replican en REST:

"Debo señalar que Paypal tiene API REST en el futuro, nuestro soporte SOAP se considera heredado ... Además, los contratos se pueden hacer cumplir con REST usando Swagger / RAML / Apiary / etc + JSON Schema, aunque algo diferente".

Violaciones específicas de la operación y CRUD

REST funciona mejor cuando una frase simple se cumple lo más cerca posible: CRUD . Crear, recuperar, actualizar y eliminar. Cuando una API tiene interacciones simples, como es el caso de la API de Facebook, donde los usuarios necesitan crear publicaciones en la línea de tiempo, recuperar las publicaciones de otros, actualizar las suyas propias y eliminar sus publicaciones, REST está bien.

El problema surge cuando la operación es el foco, más que el recurso . Con REST, CRUD opera con la idea de que el recurso es lo que debe modificarse y ampliarse; en las API que se ocupan de transacciones o modificación de datos no estáticos, SOAP es más apropiado.

WCF .NET API es intrínsecamente irresistible

WCF .NET prefiere SOAP para beneficio operativo

Un buen ejemplo de esto es la API SOAP de Windows Communication Foundation (WCF) . Esta API permite la manipulación en vivo no solo de los datos sobre los que se opera, sino también de las operaciones que se pueden realizar en su contra. Es esta modularidad y funcionalidad específica de operación lo que hace que SOAP sea tan poderoso y una buena opción frente a REST.

Más específicamente, SOAP, en este caso, llena un vacío interesante entre la idea de soportar hipermedia en la especificación de la API REST como una cuestión de principio y la realidad de manejar datos simples y sin procesar que no necesitan estar vinculados relacionalmente. La operación de reclamar una cotización, o generar un número de ticket, es tan simple que crear una API RESTful para hacerlo es un desperdicio, y cuando se combina con un gran número de solicitudes de cotización o generaciones de recibos, es absolutamente insostenible.

¿Es tan importante?

Todo esto plantea la pregunta de si es tan importante o no. La respuesta fácil es que "depende". Cuando las API violan un estándar como REST, la reacción instintiva es decir que el servicio es defectuoso. Violar los estándares de REST a los ojos de muchas personas se ha convertido en una línea negativa en la arena, algo que representa la falta de familiaridad o un enfoque juvenil del desarrollo.

El argumento REST vs SOAP tiene mucho más que ver con el estilo que con la función o la forma. Dejando a un lado el estilo y la eficiencia, cualquier cosa que se haga en SOAP se puede hacer en la variedad de lenguajes, sintaxis y enfoques que componen la mayor parte del desarrollo de REST, y del mismo modo, cualquier cosa que se pueda hacer en REST se puede hacer en alguna configuración en SOAP.

Así como un desarrollador no consideraría que una API en golang sea ​​menor que una desarrollada en Python, el mundo de las API también debería dar un paso atrás en su ferviente amor por REST, al menos, cuando esté justificado. Lo que importa es cuáles son los requisitos específicos de la API en términos de peso, velocidad de procesamiento y tipo de datos procesados.

Conclusión

Las API unRESTful son mucho más comunes de lo que uno podría pensar, a pesar de la charla de radio que sugiere lo contrario. Lo que a menudo se expresa en hipérbole como la diferencia entre "antiguo y moderno" es un argumento de estilo la mayoría de las veces, y es muy variable dado el tipo de datos y las demandas del sistema.

Por supuesto, existen situaciones en las que las demandas del emisor de datos o la entidad comercial casi requieren un formato REST específico. Para esas situaciones, REST es una restricción, más que una característica, y es algo que se debe hacer para cumplir. Eso no significa que todo en las industrias de IoT o de la salud , por ejemplo, se haga mejor con REST; solo significa que aquellos para quienes se crearon los sistemas tienden a preferir que se haga en REST. Si SOAP es más apropiado, o cualquier variación fuera de REST para el caso, el estilo debe ser dictado por el contenido donde esté permitido.

Abrirnos a aceptar SOAP, RPC y otras soluciones no RESTful solo beneficiará al ecosistema en su conjunto, creando nuevas y mejores alternativas a los sistemas que ya existen. Otras soluciones que aumentan drásticamente REST, como GraphQL , pueden ser igualmente beneficiosas, un hecho que extrapolaremos en un artículo adicional. Centrarse demasiado en REST podría tener el efecto contrario (y negativo).

Publicar un comentario

0 Comentarios