Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo optimizar el paquete de respuesta de API


 Si hay algo que tiene la mayor rentabilidad en el mundo de la TI, es la optimización . La optimización, o el proceso de simplificación, descarga o reducción de la demanda de procesamiento de una entidad, puede tener beneficios significativos para casi cualquier sistema y, cuando se realiza correctamente, puede llevar incluso al sistema más monolítico al ámbito de la alta eficiencia y la usabilidad extrema. .

Uno de los mejores lugares donde la optimización puede obtener ganancias significativas es en el paquete de respuesta API generado a partir de las solicitudes de los clientes. Estas respuestas a menudo están innecesariamente infladas por datos que pueden ser necesarios o no por cualquier motivo, y la simplificación de estas respuestas puede conducir a aumentos drásticos en la eficiencia .

Hoy vamos a discutir exactamente eso, profundizando en el concepto y proceso de optimización de la respuesta de API. Discutiremos por qué las ganancias observadas en este espacio son tan beneficiosas tanto para el desarrollador como para el usuario final, y cómo se ve funcionalmente esta optimización. También sacaremos esto de lo teórico y daremos algunos ejemplos del mundo real en acción.

Métodos de manejo de datos para la optimización

¿Cómo podemos optimizar la respuesta de una API? Si bien existe una amplia gama de soluciones de terceros, muchos de los métodos empleados se pueden usar en la base de código misma. Como tal, en este artículo discutiremos enfoques generales en lugar de abogar por soluciones específicas.

Paginación

La paginación es el principio de separar las respuestas en lotes de contenido , navegables a través de solicitudes de respuesta selectiva. En otras palabras, piense en la paginación en una API de la misma manera que lo haría con un libro: si solo desea hacer referencia a un número determinado de páginas, puede hacerlo, y navegar por esas páginas a través de números adjuntos permite una segmentación clara y más navegación eficiente.

De la misma manera, la paginación puede servir para optimizar las respuestas al tiempo que conserva la mayor cantidad de datos que se transmiten al usuario. Esto se puede hacer de una amplia variedad de formas, pero fundamentalmente hablando, en su forma más básica, la paginación debería permitir al menos:

  • Segmentación de respuestas en unidades de bloque establecidas (es decir, 10 respuestas por página, 20 respuestas por página, etc.);
  • Limitación del total de respuestas para el desarrollador (es decir, limitar la paginación a las primeras 1,000 entradas, paginadas en páginas de bloques de 10 unidades);
  • Estandarización : Los enfoques consistentes para la paginación requieren al menos el uso de algunos términos estándar o sinónimos (como el uso de "siguiente", "último", etc. para la navegación del cursor).

Ejemplo

Un gran ejemplo de paginación se puede encontrar en la cartilla HAL PhlyRestfully , y es así:

{
    "_links": {
        "self": {
            "href": "http://example.org/api/user?page=3"
        },
        "first": {
            "href": "http://example.org/api/user"
        },
        "prev": {
            "href": "http://example.org/api/user?page=2"
        },
        "next": {
            "href": "http://example.org/api/user?page=4"
        },
        "last": {
            "href": "http://example.org/api/user?page=133"
        }
    }
    "count": 3,
    "total": 498,
    "_embedded": {
        "users": [
            {
                "_links": {
                    "self": {
                        "href": "http://example.org/api/user/mwop"
                    }
                },
                "id": "mwop",
                "name": "Matthew Weier O'Phinney"
            },
            {
                "_links": {
                    "self": {
                        "href": "http://example.org/api/user/mac_nibblet"
                    }
                },
                "id": "mac_nibblet",
                "name": "Antoine Hedgecock"
            },
            {
                "_links": {
                    "self": {
                        "href": "http://example.org/api/user/spiffyjr"
                    }
                },
                "id": "spiffyjr",
                "name": "Kyle Spraggs"
            }
        ]
    }
}

En este ejemplo, lo que se está haciendo es bastante simple. Todos los resultados se desglosan a través de la paginación, y un método específico para navegar por estas entradas es proporcionado por "primero", "anterior", "siguiente" y "último". El total de entradas se especifica, al igual que el recuento, a través de " total ”y“ contar ”.

Al dividir los resultados en estos formularios paginados muy fáciles de navegar, no solo reduce gran parte de la complejidad de los resultados y, por lo tanto, se beneficia de la transformación optimizada, sino que también obtiene una experiencia de usuario mucho mejor, ya que ya no están inundados. con 498 entradas en una sola página.

Relacionado: Optimización de API para aplicaciones móviles

Filtración

El filtrado es una herramienta muy poderosa, que permite expresamente la limitación de resultados según los parámetros del propio solicitante . Esto es muy eficaz, ya que no solo reduce la cantidad total de llamadas que se realizan y los resultados que se muestran, sino que también ayuda a determinar muy específicamente qué recursos se alimentan al usuario según sus propios requisitos.

Esto tiene el efecto adicional de brindar una optimización real y tangible, al tiempo que brinda una mejor experiencia de usuario que da la ilusión de una mayor eficiencia. Si bien, en promedio, preferimos optar por una optimización real en lugar de una ilusión, el resultado final es un sistema que funciona mejor y brinda solo lo que realmente se solicita.

Sin embargo, debe tenerse en cuenta aquí que el filtrado, cuando es demasiado complejo, puede tener un efecto inverso para la optimización. De hecho, alguna lógica de filtrado compleja puede ser tan compleja que el cliente podría requerir comentarios del propio servidor antes de aplicar la lógica adicional del filtro. Esto tendría un efecto inverso en la experiencia del usuario y, si bien en teoría se optimizaría la última llamada, las llamadas que conducen a este contenido filtrado no lo serían.

En consecuencia, el filtrado debe aplicarse de manera eficaz.

Ejemplo

Un ejemplo eficaz de filtrado se puede encontrar en la API SparkPay de CapitalOne SparkPay maneja su filtrado mediante la siguiente sintaxis:

/api/v1/resource/field_name=op:value

Lo que realmente hace que estos filtros sean poderosos son los operadores de comparación que proporciona la API. "Eq", "not", "like" y otras operantes como esta permiten una gran cantidad de flexibilidad dentro de los resultados mismos, y cuando se combinan con los operadores de conjunción como "AND" / "OR", permiten un par mayor cantidad de especificidad a los resultados reales mostrados.

Lea también: No infrautilice estas 5 increíbles funciones de rendimiento HTTP

Rangos

Los rangos son un gran ejemplo de cómo restringir aún más los resultados que está recibiendo en función de una estructura específica del usuario. Cuando los datos del encabezado de rango de una solicitud de API definen un inicio y un final específicos , solo los elementos específicos dentro de ese rango se consideran aplicables para la solicitud.

Por ejemplo, si un rango de contenido se limita solo al contenido que contiene un código de estado específico o una identificación de manejo específica, podemos limitar el tamaño real del paquete de respuesta y descargar el procesamiento de los datos del lado del cliente de la ecuación y en el servidor. Si bien esto implica un manejo adicional por parte del servidor, si la base de datos se optimiza adecuadamente, utilizando vistas e índices para conjuntos de información específicos, esto puede ser extremadamente insignificante.

En realidad, esto se reduce al uso es que el usuario configura un rango de datos que se va a examinar, el servidor accede a una base de datos indexada para ese rango y luego devuelve los datos en un formato limpio, simple, fácil y reducido.

Obviamente, esto tiene un impacto bastante grande en el tamaño de la respuesta: al limitar la cantidad real de datos a solo lo que se necesita, estamos eliminando la "paja" y entregando el "trigo".

Ejemplo

IBM señala en su documentación en IBM Decision Optimization Center el uso de rangos específicamente para la entrega de contenido relacionado con códigos de estado HTTP al declarar una solicitud con un rango dado definido en content-range, bajo la siguiente estructura:

Range: items =  - 

Hay una variedad de respuestas que señala la documentación de la API, refiriéndose específicamente a cada método por la verborrea HTTP, pero fundamentalmente hablando, los rangos se utilizan como filtros para cada respuesta de contenido. Cuando se anota una respuesta 200, el rango dado por el solicitante puede resultar en entregar las 200 respuestas registradas para un servidor específico en un área específica; al entregar estos datos, y solo estos datos, la respuesta envía el contenido que se necesita para el proceso a mano.

También sobre la respuesta de la API: Prácticas recomendadas para el manejo de errores de API

Evitar la captación insuficiente y excesiva

Con todo esto dependiente del concepto de reducir la cantidad de datos que se transmiten, veamos los conceptos de captación insuficiente y captación excesiva , y los resultados de cada uno.

Estos dos conceptos son en gran medida conceptos del tipo "lo que dice en la lata": en pocas palabras, obtener más datos de los que es necesario o útil para el cliente, y menos recursos no es responder con suficientes datos, lo que a menudo requiere una llamada secundaria a otro punto final para completar el conjunto de datos. Estos dos pueden ocurrir desde el lado del cliente, con restricciones mal formadas para rangos y filtrado incorrecto, pero a menudo pueden ocurrir en la base de código como un síntoma de escalado o diseño deficiente.

En términos de búsqueda excesiva , el problema suele ser el resultado de una solicitud mal formada que cumple con una respuesta de paquete predeterminada que es demasiado amplia. Cuando estos dos problemas chocan, con el usuario no especificando correctamente los datos solicitados y la API asumiendo que quieren literalmente todo lo que tienen, obtienes respuestas que son demasiado amplias hasta el punto de ser absolutamente inútiles para el usuario final.

Por otro lado, la búsqueda deficiente es casi siempre un problema en el lado del servidor . Si bien las solicitudes incompletas pueden provenir del cliente que envía una solicitud de manera prematura, la obtención deficiente a menudo proviene de una API que se ha escalado para agregar puntos finales o nodos adicionales que manejan mayores cantidades de datos. Esto está bien para manejar más datos, pero sin la documentación adecuada o incluso la implementación de puntos finales recopilados, esto puede resultar en que un cliente llegue a un solo punto final, esperando todo lo que desea y luego obtenga resultados incompletos o códigos de error para parámetros no compatibles.

Hay algunas formas de rectificar esto. En primer lugar, con una planificación adecuada de la API, una revisión de la arquitectura puede ser de gran ayuda para garantizar que estos problemas no surjan. Al planificar el uso promedio de datos y también considerar el caso extremo como algo que debe ser compatible, las solicitudes mal formadas se pueden cumplir con consejos sobre cómo formular correctamente una solicitud, en lugar de solo una entrega vacía. Del mismo modo, comprender la escala y mantener la funcionalidad anterior es clave para garantizar que todos los datos esperados se entreguen realmente.

Para llevar esto un paso más allá, algo como GraphQL es muy poderoso contra este tipo de problema, ya que el servidor no tiene que adivinar lo que se desea: el cliente declara específicamente su solicitud y lo que obtienen es solo lo que querían.

Cabe señalar que la recuperación excesiva y la recuperación insuficiente no son necesariamente un problema con un lenguaje o marco específico, sino que son inherentes al diseño REST. En consecuencia, es importante ser consciente de esto como parte de una mayor consideración del tamaño de respuesta de la API. Obviamente, la recuperación excesiva aumenta estas respuestas, pero la recuperación insuficiente puede dar como resultado que lo que se podría hacer en una o dos llamadas se haga en cinco o más llamadas, lo que resulta en el efecto final de que los datos de una sola llamada requieren cinco llamadas para generar .

Experiencia de equilibrio

Uno de los grandes beneficios de optimizar el paquete de respuesta es el hecho de que la experiencia puede equilibrarse adecuadamente con las cualidades reales de cada aspecto del paquete en sí. En otras palabras, según el aspecto de la solicitud, la mayor parte del procesamiento y la restricción se pueden transferir a la parte responsable.

Echemos un vistazo a una API teórica para ver cómo funcionaría esto para el proveedor y para el solicitante. Imaginemos una API que proporcione datos geolocalizados para una empresa de transporte. La API comparte la ubicación de los vehículos, el tiempo promedio de entrega, el peso promedio del paquete, el procesamiento de pagos y características auxiliares adicionales.

No optimizado

En nuestro primer ejemplo, no hay ninguna optimización del paquete de respuesta de la API. Cuando los gerentes llaman a la API para ver dónde están los vehículos, obtienen la suma total de los datos del vehículo, la información de procesamiento de pagos, etc.

Para los gerentes, esto es problemático, ya que muchos de ellos usan dispositivos móviles livianos para moverse de un sitio a otro. Como tal, la cantidad de datos que se envían a los dispositivos es extremadamente pesada y, a menudo, resulta en una carga lenta , ya que los datos se entregan en un sitio web autenticado centrado en dispositivos móviles.

Esto es especialmente problemático para el departamento de pagos, ya que solo se preocupan por los pagos, pero deben analizar datos adicionales para cada llamada. El problema tampoco se detiene allí: para cada departamento, los datos adicionales que no se necesitan terminan obstruyendo los sistemas de procesamiento y resultan en una actualización bastante lenta de los datos internos.

Si bien los problemas internos son problemáticos, la situación es aún peor para los clientes que han pedido el envío. La API que proporciona datos de vehículos también sirve para la fecha de entrega esperada, y esta fecha suele tardar en actualizarse debido a la abrumadora cantidad de datos que se envían a través del sistema. Esto resulta en actualizaciones lentas para los clientes , lo que lleva a una menor satisfacción por el servicio en general.

Optimizado

Ahora veamos una solución optimizada. Aprendiendo de sus errores, los desarrolladores de API han tomado la API monolítica y la han rediseñado. En primer lugar, la API se divide en una serie de microservicios: no es necesario que una única API haga tanto y pase tantos datos. Desde el principio, esto da como resultado una mayor eficiencia, ya que los datos que envía una única API se han dividido en cinco API, lo que teóricamente reduce la carga máxima de tráfico en 1/5.

Una vez que la API se dividió correctamente en una serie de microservicios , se analizó el problema de los grandes paquetes de respuesta. En primer lugar, se implementó la paginación como un método para que los gerentes generales vieran las entregas activas de una manera navegable. Debido a que el sitio móvil se basa en mostrar datos relevantes para el administrador, la paginación ha permitido una navegación más fácil y una mayor cantidad de control sobre agrupaciones específicas de estos datos.

Yendo un paso más allá, se aplicó el filtrado para que las oficinas de procesamiento de pagos pudieran ver los detalles de pago para camiones y regiones específicas. Al aplicar este filtrado, se pueden eliminar grandes cantidades de datos del paquete de solicitud, lo que significa que las oficinas de pago, que manejan una mayor cantidad de llamadas que la mayoría de los departamentos de la organización, utilizan menos red mientras manejan de manera más eficiente los datos necesarios. .

Finalmente, los rangos se especificaron como una opción para la propia llamada. Ahora, el cliente puede elegir ver la información de envío exacta. pertinente a su (s) número (s) de identificación de seguimiento. Esto se implementó en lugar de búsquedas de ID de clientes u otras soluciones similares porque, en este caso, se puede abrir más de un envío a la vez para un solo consumidor, pero al consumidor solo le importa un solo envío y no el resto. .

Si bien esto tiene impactos obvios en la eficiencia de la organización, una gran parte de los ahorros en realidad proviene de la reducción de la necesidad de infraestructura física. Al reducir la complejidad de la API en una serie de microservicios y reducir drásticamente la carga de respuesta real, se necesita menos infraestructura, lo que no solo beneficia enormemente a las oficinas en los condados rurales, sino que también reduce el costo general de operación en toda la empresa.

Reflexiones finales: por qué nos beneficiamos de la optimización del paquete de respuesta

¿Qué tiene la optimización que conduce a ganancias tan dramáticas? En pocas palabras, es una línea de comunicación más directa entre el proveedor de recursos y el solicitante de recursos. Esto significa que el paquete de respuesta es excepcionalmente primordial para los procesos de optimización y tendrá impactos distintos y visibles en ambos lados de la ecuación.

En cada etapa del encuentro con la solicitud y la respuesta de la API, el tamaño y el nivel de optimización tiene una relación directa con la experiencia de la entidad en cuestión, ya sea el desarrollador o el receptor. De esta manera, incluso una pequeña disminución del 5% en términos de procesamiento requerido y tamaño del paquete de respuesta puede tener un efecto compuesto no solo en la experiencia del usuario, sino también en la experiencia del desarrollador .

Debido a esto, la optimización es enormemente poderosa. El efecto real en la experiencia se debe a una carga más rápida, menos estrés general en la red y compuestos de base de código optimizados de manera espectacular, especialmente en miles de llamadas.

Optimizar el paquete de respuesta es una de las técnicas más importantes que un proveedor puede utilizar cuando intenta hacer un sistema eficiente. Cuanto más eficiente sea el sistema, menos problemas debe esperar. El hecho de que mejore las experiencias de los desarrolladores y los consumidores debería ser suficiente, pero incluso sin tener en cuenta eso, los beneficios operativos que se obtienen al optimizar el paquete de respuesta son numerosos.

¿Cuál crees que es la mejor manera de optimizar los paquetes de respuesta para las API web? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios