Interface PaginatedPostBody

All Known Implementing Classes:
BillingAccountSearchRequest, FilteredPaginatedPost, FilteredSortedPaginatedPost, SearchRequest
public interface PaginatedPostBody
A POST-search request body that carries client-side pagination state, so the shared paging pipeline (PaginatedList/PaginatedFilteredList next()/loadAll()) can re-point the body at the next page between fetches without knowing the body's concrete type or how it represents pagination.

The contract is deliberately behavioral rather than representational: bodies with heterogeneous pagination models - the core Pagination {offset, limit} object (FilteredSortedPaginatedPost, FilteredPaginatedPost), IBX SmartView's SearchPagination {offset, limit}, or flat top-level offset/limit members (billing accounts search) - all implement it by mapping the requested window onto their own serialized shape.

The paging pipeline always seeks from the server-reported pagination of the page it holds: the next page starts at serverOffset + serverLimit with the server's (possibly clamped) limit, and a failed fetch seeks back to serverOffset so a retried next() re-requests the same page. Domain search bodies must implement this interface if their results are exposed through a pageable list; a body that does not implement it fails paging fast with a clear EquinixClientException instead of a ClassCastException.

  • Method Summary

    Modifier and Type
    Method
    Description
    void
    seekPage(long offset, long limit)
    Points this body's serialized pagination state at the page window starting at offset, sized limit.

  • Method Details

    • seekPage

      void seekPage(long offset, long limit)
      Points this body's serialized pagination state at the page window starting at offset, sized limit. Called by the paging pipeline both to advance to the next page and to roll back to the current page after a failed fetch.
      Parameters:
      offset - the zero-based index of the first record of the requested page
      limit - the page size; implementations should ignore non-positive values (keeping their current/default limit) rather than sending an invalid one