Great question! I’ve wrestled with this exact dilemma when designing APIs, especially since Spring’s default approach feels so intuitive but I’ve seen plenty of debates favoring limit+offset. Let’s break this down.

First: What’s the Difference Between the Two Approaches? #

Let’s clarify the basics with your examples:

• page + size: Page-based pagination. page=1&size=20 means "give me the first page, with 20 items per page". Users think in terms of pages, just like a book.
• limit + offset: Offset-based pagination. limit=20&offset=0 means "give me 20 items starting from the 0th position". This is more low-level, tied directly to how databases fetch results.

Why Spring Defaults to page+size #

Spring’s choice isn’t arbitrary—it aligns with its core design principles and real-world development needs:

1. Better Intuition for Most Users & Teams
   Non-technical stakeholders (like product managers or customer support) understand "page 3, 20 items per page" instantly. Offset-based pagination requires mental math (e.g., "to get page 3, offset is (3-1)*20 = 40") which creates friction in communication and frontend integration.

2. Spring Data’s Abstraction Focus
   Spring Data (JPA, MongoDB, etc.) is built to simplify data access. The Pageable interface and Page return type are designed to encapsulate pagination logic at a higher level. Page includes metadata like total pages and total elements, which are natural extensions of page-based pagination—you don’t get that kind of context with raw limit+offset results.

3. Seamless Frontend Integration
   Almost every popular frontend UI framework (Element UI, React Table, Vue Pagination) ships with pagination components that natively use page and size as input parameters. Using Spring’s default means you don’t have to write extra code to convert between offset/limit and page/size for your frontend team.

4. Mitigates Common Offset Pitfalls (Sort Of)
   While both approaches suffer from consistency issues when data changes (e.g., items being added/deleted between page loads), offset-based pagination can perform poorly with large datasets. Databases like MySQL have to scan all rows up to the offset before returning results, which gets slower as offset grows. Page-based pagination doesn’t fix this inherently, but Spring makes it easier to switch to keyset pagination (using unique ordered fields) later if you need better performance—without rewriting your entire pagination contract.

Why Do Some Developers Prefer limit+offset? #

Don’t get me wrong—offset-based pagination has its place:

• Greater Flexibility: It’s easier to fetch non-standard ranges (e.g., "give me 15 items starting from position 42") which page-based pagination doesn’t handle natively.
• Closer to Database Native Syntax: SQL’s LIMIT offset, limit is a direct match, so some developers prefer working with this lower-level approach for complex queries.
• Avoids "Page Number Drift": In scenarios where data is updated frequently, page numbers can shift (e.g., deleting an item from page 1 pushes page 2’s first item to page 1). Offset-based pagination has the same issue, but some teams perceive it as more "stable" because it’s tied to absolute positions.

Final Takeaway #

Spring defaults to page+size because it’s the most practical choice for 90% of business applications. It’s easier to reason about, integrates smoothly with frontend tools, and fits Spring Data’s abstraction-focused philosophy. That said, if you need the flexibility of limit+offset, Spring doesn’t lock you in—you can easily parse custom parameters and convert them to a Pageable object, or use native queries directly.

内容的提问来源于stack exchange，提问作者MaxExplode