Further Reading: API Ingestion

Sources are tagged Tier 1 (confident it exists, recommended without reservation) or Tier 2 (real and worth seeking, but confirm the current edition, version, or URL yourself).

API ingestion has almost no dedicated literature, because it is regarded as plumbing. What exists is scattered across HTTP specifications, cloud providers' reliability guidance, and individual APIs' documentation — which is where most of this list comes from.

On retries, backoff, and the failures they cause

Marc Brooker, "Timeouts, retries, and backoff with jitter" (AWS Builders' Library). The primary source for §16.5. It is where "full jitter" is compared against "equal jitter" and no jitter with actual simulation results, and it explains why full jitter wins. Ten minutes, and it will change how you write a retry loop. Tier 2 — AWS content moves, but the Builders' Library has been stable.
The AWS Builders' Library more generally, particularly "Avoiding fallback in distributed systems," "Using load shedding to avoid overload," and "Timeouts, retries and backoff." Written by people operating systems where a retry storm is measurable, and unusually candid about mechanisms that make things worse. §16.6's central claim — that backoff without classification amplifies the problem — is their argument. Tier 2.
Marc Brooker's personal blog (brooker.co.za/blog). The long-form version of the same thinking, especially on retry budgets and on why client-side retry is a load-amplification mechanism. Tier 2.

The specifications

RFC 9110, "HTTP Semantics." The current HTTP specification, superseding RFC 7231. Read the status-code sections once so that §16.6's classification is grounded in what each code means rather than in a table you memorized. In particular: 4xx is "the client seems to have erred" and 5xx is "the server is aware it has erred" — which is the whole justification for the fail-unknown-4xx, retry-unknown-5xx default. Tier 1.
RFC 9110 §10.2.3 on Retry-After. Two paragraphs, and it specifies both accepted forms — delay-seconds and an HTTP-date. Clients that handle only the integer form crash on the other, in production, during an incident. Tier 1.
RFC 6585 §4 (status 429) and the IETF RateLimit header fields draft. The 429 definition, and the ongoing effort to standardize the rate-limit headers that every API currently spells differently. Worth tracking: if it lands, §16.3's header-name archaeology gets simpler. Tier 2 — the draft is a moving target.
RFC 8594, the Sunset HTTP header, and the Deprecation header draft. The mechanism by which APIs warn you before removing something. This chapter's first case study caught a deprecation five months early by counting response headers; knowing these exist is what makes that possible. Tier 2.
RFC 5988 / RFC 8288, "Web Linking." The Link header format, for §16.2's fourth pagination shape. Short, and worth reading because the header is comma-separated with quoted parameters and naive parsers get it wrong. Tier 1.

On pagination specifically

The Slack, Stripe, and GitHub API documentation on pagination. Three well-designed APIs with three different approaches — Slack uses cursors, Stripe uses object-id-based cursors with starting_after, GitHub uses link headers. Reading all three is the fastest way to internalize §16.2, and each documents its own failure modes better than a general treatment can. Tier 2 — versioned, and all three have changed.
"Pagination: You're (probably) doing it wrong" and similar write-ups on keyset versus offset pagination. The database-side version of the same argument — offset pagination is also slow at depth, because the database must count past the offset — which is a second reason to avoid it that §16.2 did not have room for. Tier 2 — blog content; several good ones exist.

On authentication

RFC 6749 (OAuth 2.0) and RFC 6750 (Bearer Token Usage). Read §4.4 (client credentials) and §6 (refreshing an access token) of RFC 6749. The specification is clearer than most tutorials about what a refresh token is and is not, and about the fact that a provider may issue a new refresh token on each use — which is the behavior that makes §16.4's thread-safety note necessary. Tier 1.
The OAuth 2.1 draft, which consolidates a decade of security guidance. Worth knowing exists; the practical difference for a data engineer is mostly the removal of flows you should not have been using. Tier 2.

On testing against systems you do not control

The VCR / vcrpy / betamax family of libraries. Record-and-replay HTTP for tests. Read the documentation for the cassette staleness problem, which is §16.9's first layer's weakness and which the libraries themselves discuss. Tier 2.
Pact and the consumer-driven contract testing literature. A more formal approach to §16.9's contract test, designed for services you own on both sides. Less applicable to a third-party API, and the framing — that a contract is a shared artifact rather than one side's documentation — transfers directly to Chapter 17. Tier 2.
The Singer and Airbyte connector specifications, recommended in Chapter 13 and relevant again: both define how a connector should handle pagination, state, and rate limits, and reading how someone else formalized it sharpens your own. Airbyte's low-code connector spec in particular has an explicit declarative model for pagination and rate limiting that is worth studying as a taxonomy. Tier 2.

If you only read one thing

Read Marc Brooker's "Timeouts, retries, and backoff with jitter."

It is short, it has graphs, and it is the source of the two rules in this chapter that most reliably prevent incidents: jitter is not optional, and a retry mechanism is a load-amplification mechanism whose behavior under correlated failure is the thing you have to reason about.

Then, before you ship an API client, read RFC 9110's status code sections — twenty minutes — so that your error classifier is grounded in what the codes mean rather than in a table. The fail-unknown-4xx default is a direct consequence of the specification's own words, and knowing that makes it defensible in review rather than arbitrary.