Batch endpoints avoid N+1 client calls

An API with no batch endpoints forces consumers to implement N+1 request loops for common multi-item operations — deleting 50 selected items requires 50 sequential DELETE calls. Each request adds latency, each adds load, and on high-latency connections the cumulative cost is severe. iso-25010:2011 performance-efficiency.time-behaviour is the direct impact: an operation that could complete in one round-trip takes N round-trips because the API surface was not designed for the real usage pattern the client requires.

Add batch endpoints for the most common multi-item operations your UI already supports. Always enforce a maximum batch size:

// Batch delete: DELETE /api/items/batch
// Body: { ids: ["id1", "id2", "id3"] }

// Batch create: POST /api/items/batch
// Body: { items: [{ name: "A" }, { name: "B" }] }

// Enforce a maximum in every batch handler:
const MAX_BATCH_SIZE = 100
if (ids.length > MAX_BATCH_SIZE) {
  return apiError('BATCH_TOO_LARGE', `Maximum ${MAX_BATCH_SIZE} items per batch`, 400)
}

Prioritize batch endpoints for operations the UI already performs in loops — look for for...of or .map() around fetch() calls in your client code as the signal.