Why this matters
- Idempotency, rate limits, and pagination separate demo APIs from production BookStore endpoints.
- Payment and order flows are where retry semantics and duplicate POSTs hurt revenue.
- Staff interviews probe how you document and enforce these contracts in OpenAPI and gateways.
Idempotency keys
L1 · FresherClients send Idempotency-Key on POST; BookStore stores outcomes so retries do not double-charge orders.
Rate limiting
L2 · IntermediateProtect APIs with gateway limits or Resilience4j rate limiters — return 429 with Retry-After when exceeded.
Multipart uploads
L3 · AdvancedUse MultipartFile for cover images with size limits and virus scanning hooks before S3 upload.
Pagination contracts
L4 · ExpertStandardize on page, size, and sort parameters with total counts — avoid unbounded findAll on catalog endpoints.
Hook
BookStore ships to production behind a load balancer. Clients need stable pagination, consistent error JSON, idempotent order placement, and rate limits during flash sales — not ad-hoc controller shortcuts that worked on localhost.
Versioning and media types
Prefer URL versioning for public APIs: /api/v1/books. Document supported Accept and Content-Type values. Breaking changes get a new path prefix; sunset old versions with Deprecation response headers and a published timeline.
The rest of this guide is part of Pro
Free covers every fresher guide in full. Pro unlocks Senior, Staff and Architect guides across every track.
Still to come · 8 sections
- Pagination and filtering
- Problem Details for errors
- Idempotency keys
- Observability headers
- BookStore in action
- Runnable BookStore lab
- Failure modes in production
- Caching semantics
Test yourself
Answer these before moving on — recall is what makes it stick.