Recommended approaches for API pagination using Apigee

Google Cloud Apigee
1

Hello everyone,

I’m working on a web application that consumes REST APIs with paginated responses.

I’d like to know the recommended best practices for handling pagination on the frontend and backend, especially in terms of performance and user experience.

Any guidance or examples would be appreciated.

Thank you

1 Like
2

Hello @Shahzaib_Aziz ,

Could you elaborate a bit further as per your technology stack (both client and server side)? Is Apigee being used as a front end to your target service, and would you expect logic in Apigee to help facilitate your pagination requirements?

Any additional details you could provide would be appreciated, thanks!

Best
Matt

Best practices for handling API pagination in a web application
3

Hi Matt,

Thanks for your response.

On the client side, we are using a REST-based client application.
On the server side, we have a Node.js backend exposing REST APIs.

Apigee is being used as an API gateway in front of the backend services (client → Apigee → backend).
Currently, pagination logic is implemented at the backend level, and Apigee mainly acts as a proxy layer.

However, we are exploring whether Apigee policies can assist with pagination handling or response shaping when dealing with large datasets.

Please let me know if you need any additional details.

Thanks again,
Shahzaib

4

Hey @Shahzaib_Aziz ,

Thank you for the detailed response! Given the above, Apigee could absolutely help from the following perspectives:

  1. Response mediation as you noted - I’m not sure if there is only one backend in your architecture but Apigee can very easily aggregate responses across multiple, paginated endpoints (via Service Callout, External Callouts, etc)
  2. Response caching - if similar pages are being requested you can cache this data to remove the performance overhead of hitting the backend service everytime (see more here: api-platform-samples/sample-proxies/pagination at master · apigee/api-platform-samples · GitHub - though it is XML most of the workflow still applies)

Besides the above I would assume your typical quota policies would apply (to ensure that users aren’t overly requesting data)

Hope this helps, thanks!

Best
Matt

5

Hi Matt,

Thanks a lot for the detailed explanation — this is very helpful.

At the moment we primarily have a single backend service, but we do have multiple endpoints that expose paginated data. The response aggregation capability you mentioned via Service Callouts is definitely something we will explore, especially as the architecture evolves.

Response caching also makes a lot of sense for our use case, since we do see repeated access to the same pages. We’ll review the sample you shared and evaluate how best to adapt that workflow in our setup.

We are already using quota policies, but your points around combining these with caching and mediation are very useful from a design perspective.

Thanks again for the insights — much appreciated!

6

Thank you for the thoughtful follow-up and for sharing additional context around your current architecture and it’s good to hear that response aggregation via Service Callouts is on your radar. Even with a single backend service today, exploring this pattern early can provide useful flexibility as your API surface and downstream dependencies grow.

7

Thank you for your reply and for the additional insights. We agree that exploring response aggregation early will be beneficial as our API landscape evolves. We’ll continue evaluating Service Callouts and caching strategies as part of our design considerations. Appreciate the guidance.

1 Like