Saltar al contenido principal
Gestionar grandes conjuntos de datos de manera eficiente es crucial para mantener el rendimiento y la escalabilidad de las APIs. Nuestras APIs emplean un mecanismo robusto de paginación para entregar datos en porciones más pequeñas y manejables. Esto mejora los tiempos de respuesta y el procesamiento del lado del cliente, particularmente para aplicaciones que cargan resultados de forma incremental.

​
Paginación en nuestras APIs

En lugar de devolver todo el conjunto de datos en una sola respuesta, lo que puede sobrecargar los recursos, los clientes pueden solicitar subconjuntos específicos de datos. Esto mejora los tiempos de respuesta y permite un manejo de datos más fluido, particularmente para aplicaciones que cargan resultados de forma incremental. Soportamos dos parámetros de consulta para la paginación:
  • page (entero): Especifica el número de página a recuperar. El valor predeterminado es 1.
    • Los valores negativos no son válidos y resultarán en un error.
  • limit (entero): Define el número máximo de elementos por página. El valor predeterminado es 10.
Por ejemplo, para recuperar la primera página de organizaciones con un máximo de 10 elementos por página: 
GET /v1/organizations?page=1&limit=10

​
Respuesta de paginación

La respuesta de paginación incluye la siguiente estructura:
  • items: Un array de entidades recuperadas para la página actual. Cada objeto contiene información detallada sobre el recurso solicitado, como se muestra en el ejemplo a continuación.
  • page: El número de página actual, comenzando desde 1 (predeterminado).
  • limit: El número máximo de elementos incluidos en la respuesta, según se define en la solicitud o la configuración predeterminada.
A continuación se muestra un ejemplo de respuesta para una solicitud paginada: 
{
    "items": [
        {
            "id": "0193696f-8eff-7926-a77a-0b424cf7156b",
            "parentOrganizationId": null,
            "legalName": "Collins Inc",
            "doingBusinessAs": "The ledger.io",
            "legalDocument": "78425230000190",
            "address": {
                "line1": "Avenida Paulista, 1234",
                "line2": "CJ 203",
                "zipCode": "01310916",
                "city": "New Lyla",
                "state": "CH",
                "country": "FO"
            },
            "status": {
                "code": "ACTIVE",
                "description": "Ledger Test"
            },
            "createdAt": "2024-11-26T17:05:39.071587Z",
            "updatedAt": "2024-11-26T17:05:39.071587Z",
            "deletedAt": null,
            "metadata": {
                "bitcoinn": "3QH2XV7JxMRKXDqh87JG7LWuf7AeGfy",
                "boolean": true,
                "chave": "metadata_chave",
                "double": 10.5,
                "int": 1
            }
        }
    ],
    "page": 1,
    "limit": 1
}

​
Tamaño máximo de página

Por defecto, los endpoints de la API que soportan paginación aceptan un máximo de 100 elementos por página (limit=100). Esta restricción ayuda a garantizar un rendimiento óptimo y evita tamaños de carga útil excesivos. Si tu caso de uso requiere recuperar un mayor número de elementos por solicitud, puedes sobrescribir este límite configurando la variable de entorno MAX_PAGINATION_LIMIT en tu configuración de despliegue (archivo .env).
ImportanteAumentar el límite de paginación puede resultar en tiempos de respuesta más lentos dependiendo del volumen de datos y las condiciones de la infraestructura. Asegúrate de realizar pruebas exhaustivas en entornos de staging antes de aplicar el cambio en producción.
Para actualizar esta configuración en Kubernetes: 
kubectl edit configmap midaz-transaction -n midaz

# Set the new value for MAX_PAGINATION_LIMIT

kubectl rollout restart deployments midaz-transaction -n midaz
Este comportamiento es heredado por Midaz y todos sus servicios plugin.