Two of my engineers have been arguing for two days about the next API change: one endpoint with a mode parameter, or two separate endpoints. I have to call it. Which one?

Option B is the stronger default because summary and full are materially different response shapes with different contract and operational needs. Two explicit endpoints give each response a fixed, individually documented schema, which makes OpenAPI contracts, client code generation, static typing, and versioning clearer. They also allow independent policies for caching/TTLs, rate limits, auth scopes, monitoring, and deprecation without forcing a single handler to branch on a mode parameter. A mode parameter can make the response schema parameter-dependent, accrete conditional logic, and create a real caching risk if proxies/CDNs ignore query strings and serve a full response for a summary request. The main cost of two endpoints, keeping handlers in step, is usually small if both delegate to a shared service layer, so the DRY benefit of one route is mostly internal and can be preserved. Option B is also more reversible: collapsing two routes later can keep old paths as non-breaking aliases, while splitting a widely used mode endpoint later forces client migrations. Option A remains defensible and even simpler if summary and full are pure projections of identical logic with identical auth, caching, and lifecycle requirements, but that is not established here, and the expected divergence makes B the lower-risk long-term choice.