liveBook · Manning

Upper bound

As explained in API Design Patterns

An upper bound is a maximum permitted size or value that a quantity cannot exceed.

An upper bound is a maximum permitted size or value that a quantity cannot exceed. API designers use it to control numeric ranges, collection growth, and response sizes. section 5.3.1 section 5.7.1

Use upper bounds deliberately:

  • For numeric fields, choose storage that covers the intended range while accounting for lower bounds and zero. section 5.3.1
  • For maps, bound the number of keys and values, then limit individual key and value lengths. section 5.7.1
  • Prefer separate structured fields over an ever-growing map with one aggregate character limit. section 5.7.1

Pagination with maxPageSize

A paginated API can return up to 10 results instead of requiring exactly 10. If matching rows are widely distributed, stopping at a time cutoff can preserve latency and continue from the next request. section 21.3.1

How API Design Patterns covers it

How deep it goes
Explains numeric storage ranges, map-size constraints, and latency trade-offs, but stops short of implementation details.
Examples
Demonstrates 8-, 32-, and 64-bit numeric ranges, bounded map fields, and a maxPageSize pagination scenario.
What it assumes
Assumes familiarity with API fields, numeric types, maps, and pagination; explains boundary effects and storage concerns.
What you can do after
Apply it via API field design by selecting numeric ranges, bounding collections, and allowing partial pages when latency requires it.
How it connects
Connects upper bounds with lower bounds, zero values, numeric data types, maps, lists, and pagination.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of API Design Patterns. The section links point to the parts of the book it draws on.