API Style & Pattern Comparisons

Clients routinely operate on many items at once — imports, syncs, bulk tagging — and per-request overhead dominates the work.

You can't answer "what happens when item 3 of 5 fails?" — a batch without partial-failure semantics is a trap, not a feature.

One round trip and one auth check for N items; the server can bulk-insert and validate as a set.

One bad item 500s the whole batch of 500 with no per-item report — the client can't tell what committed.

Per-item result envelopes, batch size caps, atomicity documentation, and retry guidance for partially-applied batches.

Operations are independent, per-item semantics are simple, and existing retry, rate-limit and error handling should just work.

A client needs 500 items done and your rate limit is 10 req/s — you've made the network chatter the product's bottleneck.

Uniform semantics: every request has one status code, one retry decision, one log line; failures isolate naturally.

500 sequential calls at 50ms RTT is 25 seconds of wall clock; parallelizing them trips the rate limiter instead.

Connection pool and rate-limit headroom sized for bursts; clients build their own concurrency and backoff machinery.