Header Ads Widget

Ticker

6/recent/ticker-posts

5 ideas para crear API más rápidas


 En 2006, Google descubrió que 500 milisegundos adicionales de latencia podrían reducir el tráfico hasta en un 20% . Eso fue hace doce años; ahora los usuarios de la web esperan respuestas más rápidas que nunca, y como practicante de API , ¡es su deber hacer que eso suceda!

La creación de API ultrarrápidas no es fácil, especialmente cuando se intenta equilibrar la baja latencia con los principios de diseño conflictivos de apertura y flexibilidad. Entonces, para ayudarlo en su búsqueda para construir API rápidas , ¡hemos recopilado cinco de nuestras ideas favoritas para disminuir la latencia sin hacer sacrificios bárbaros!

1) Diseño de puntos finales prácticos

La primera sugerencia y la más orientada al diseño para mejorar la velocidad de la API es crear puntos finales prácticos y centrados en el usuario para su API. Si bien esto no reduce la latencia en sí, que va a minimizar el número de llamadas a los desarrolladores tienen que hacer, lo que reduce la latencia acumulada de esas llamadas y hacer que su API sensación más rápido.

Si los desarrolladores necesitan realizar una llamada para encontrar el user-idasociado con un determinado email, y luego otra llamada para encontrar el correspondiente address, todo el proceso llevará el doble de tiempo, sin importar cuánto optimice las latencias de las llamadas individuales en sí mismas, que si los desarrolladores pueden ir directamente de la información que tienen a la información que necesitan .

Por supuesto, diseñar puntos finales prácticos no siempre es tan fácil como parece. Es difícil predecir las circunstancias exactas detrás de los motivos de los desarrolladores; incluso entonces, tener docenas de puntos finales inconexos y específicos de la aplicación puede complicarse rápidamente y definitivamente no se presta a una de esas arquitecturas de microservicios de moda .

Ahora, en lugar de hacer dos llamadas separadas, podemos simplemente llamar a un solo punto final y obtener toda la información requerida. Pero recuerde que hay una compensación. Para obtener una API más robusta, nos alejamos de un patrón de diseño REST y vinculamos dos entidades relacionadas: usuario y dirección. Wojtek Erbetowski, Polidea

2) Apoyar recursos parciales

Nuestra siguiente sugerencia para acelerar su API es admitir recursos parciales . El mejor ejemplo de un recurso parcial es una respuesta parcial, donde las solicitudes se modifican con el fieldsparámetro para que los desarrolladores solo reciban las porciones de datos que solicitan en una solicitud.

Al entregar una respuesta parcial, reduce el tamaño total de la solicitud, lo que significa que hay menos datos para enviar y se puede completar más rápido. Como beneficio adicional, excluir datos innecesarios puede facilitar que los desarrolladores analicen la respuesta.

Un recurso parcial alternativo es la patchsolicitud. En este caso, los desarrolladores pueden "parchear", o actualizar, seleccionar campos de datos en lugar de reescribir todo el recurso. Misma historia: solicitudes más pequeñas significan solicitudes más rápidas .

3) Comprimir respuestas de datos

Si desea reducir la latencia sin sacrificar ningún dato, la compresión podría ser la respuesta. En este caso, puede usar una herramienta como gzip para comprimir respuestas más grandes antes de entregarlas. Por supuesto, esto significa que sus desarrolladores tendrán que extraer las respuestas del lado del cliente.

Esto debería hacer que su API sea un poco más rápida en términos de latencia, pero las desventajas son la carga adicional en el servidor (ya que comprime los datos) y la carga adicional en el cliente (a medida que extraen los datos). Para algunos, especialmente aquellos que sirven grandes cargas útiles (como imágenes de alta resolución, archivos de audio o videoclips), la recompensa vale la pena, ¡pero tendrá que determinarlo usted mismo!

Una forma fácil y conveniente de reducir el ancho de banda necesario para cada solicitud es habilitar la compresión gzip. Aunque esto requiere tiempo de CPU adicional para descomprimir los resultados, la compensación con los costos de red generalmente hace que valga la pena. Portal para desarrolladores de Blogger

4) Negociar formatos efectivos

La negociación de contenido es el mecanismo que permite a los desarrolladores elegir el formato que más les convenga, cuando hay varios disponibles. Si bien esto suena como un enfoque para admitir tipos de archivos heredados, y lo es, también es una forma divertida y única de reducir la latencia para algunas solicitudes.

De vez en cuando, aparece un nuevo formato de archivo de imagen que comprime mejor las imágenes que JPEG o PNG. Hemos visto a Google impulsando su propio formato Webp (supuestamente un 26% más pequeño en tamaño en comparación con PNG), y los nuevos formatos BPG y FLIF son competidores, empaquetando imágenes en cada vez menos espacio y tiempo que sus predecesores. Bill Doerrfeld, API nórdicas

Vea, si no usa la negociación de contenido , probablemente solo admita los formatos de archivo más antiguos y voluminosos para imágenes, videos y más. Al implementar la negociación de contenido, permite que quienes admiten formatos más nuevos y elegantes reciban archivos más pequeños y, por lo tanto, respuestas más rápidas.

Como explicamos en nuestro artículo sobre el tema de la negociación de contenido , esta es una característica sorprendentemente fácil de implementar:

Los navegadores pueden enviar información como parte de cada solicitud sobre las representaciones que prefieren, con factores q para indicar la preferencia de uso en relación con otros idiomas, formatos de texto y tipos de imágenes. Entonces, el servidor responde de la mejor manera posible a estas necesidades.

5) Transmitir donde corresponda

Como otro enfoque más específico para crear API más rápidas, considere una API de transmisión . Con las API de transmisión, el desarrollador realiza una solicitud inicial y el servidor envía respuestas continuamente a medida que se ponen a disposición nuevos datos.

Compare eso con la alternativa: los datos están disponibles, se quedan un rato hasta que el desarrollador hace una solicitud y solo entonces se envían desde el servidor. Streaming elimina las solicitudes repetidas enviadas desde el desarrollador al servidor, ¡reduciendo efectivamente a la mitad la latencia!

Estudio de caso: Twitter
Además de utilizar cargas útiles habituales, los desarrolladores pueden solicitar datos de la API de Twitter mediante una API de transmisión. De esta manera, Twitter actualiza a los desarrolladores cada vez que los usuarios elegidos publican un Tweet o actualizan su perfil, en lugar de que los desarrolladores envíen solicitudes repetidas. Esto reduce el tiempo que tardan las solicitudes de los desarrolladores en llegar a los servidores de Twitter y, como beneficio adicional, elimina las solicitudes innecesarias.

En lugar de entregar datos en lotes a través de solicitudes repetidas de su aplicación cliente, como podría esperarse de una API REST, se abre una sola conexión entre su aplicación y la API, y se envían nuevos resultados a través de esa conexión cada vez que ocurren nuevas coincidencias. Esto da como resultado un mecanismo de entrega de baja latencia que puede admitir un rendimiento muy alto. Portal de desarrolladores de Twitter

Pensamientos finales

Acelerar una API no es fácil y casi imposible si no está dispuesto a comprometerse. Sin embargo, hemos visto que definitivamente hay opciones para reducir la latencia y mejorar la velocidad efectiva de su API sin hacer demasiados sacrificios, especialmente si está dispuesto a construir con un propósito y otros principios clave de diseño en mente.

Publicar un comentario

0 Comentarios