How should I decide between a single REST endpoint or multiple specialized ones?

[JasonZR]

I’m trying to decide between using a single, broad REST endpoint for our client app or breaking it into several specific ones. The all-in-one approach would simplify the initial client code but feels like it might hurt maintainability later, especially if we need to version parts of the API independently.

[JerryJM]

We started with one all-in-one surface, /api, and the payload kept growing as features shipped. It made client logic brittle, and every new version required changes on the client side. Splitting into /v1/users, /v1/products, /v1/orders reduced coupling and made independent versioning easier, even if it meant more boilerplate up front. We also added a gateway to keep cross cutting concerns like auth and logging consistent.

[William54]

If the app is still early, the all-in-one can be fine, just set a clear deprecation plan and use smart query params to filter. A small client library that maps to resources helped us stay sane.

[TimothyQM]

Is the real problem maybe not the endpoint shape but how teams coordinate changes? If frontend teams keep reworking things, you might need contracts or consumer driven tests?

[Anthony.W]

We tried both and still ended up with a mix. The backend stayed modular but the API surface was hard to memorize; keeping one entry point slowed feature delivery because different teams touched different parts.