Saltar al contenido principal
Gestionar eficientemente grandes conjuntos de datos es crucial para mantener el rendimiento y la escalabilidad de la API. 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 incrementalmente.

​
Paginación en nuestras APIs

En lugar de devolver el conjunto de datos completo 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 incrementalmente. Admitimos dos parámetros de consulta para la paginación:
  • page (integer): Especifica el número de página a recuperar. El valor predeterminado es 1.
    • Los valores negativos son inválidos y resultarán en un error.
  • limit (integer): 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 arreglo 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, como se define en la solicitud o 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 API que admiten 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 payload excesivos. Si su caso de uso requiere recuperar un mayor número de elementos por solicitud, puede anular este límite configurando la variable de entorno MAX_PAGINATION_LIMIT en su configuración de despliegue (archivo .env).
Aumentar 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úrese de probar exhaustivamente 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

# Establezca el nuevo valor para MAX_PAGINATION_LIMIT

kubectl rollout restart deployments midaz-transaction -n midaz
Midaz y todos sus servicios de plugin heredan este comportamiento.