What a Good API Design Looks Like (And Why Most Are Overcomplicated)

Daniel Gorlovetsky

June 27, 2025

APIs are supposed to simplify things. But most of the ones we see in the wild do the opposite.

At TLVTech, we’ve worked on backend systems across dozens of startups—from quick MVPs to enterprise-scale platforms. And if there’s one thing we consistently fix, it’s overcomplicated, unclear, or inconsistent API design.

A good API doesn’t just “work.” It’s obvious. It’s boring. It’s predictable.

Here’s what a clean API looks like—and why so many teams get it wrong.

‍

1. Clear Naming Is 80% of the Work

You don’t need to read a spec to understand what POST /users/123/reset-password does. But POST /core/actions/trigger? That’s a guessing game.

Good APIs:

Use nouns for resources (/users, /projects, /sessions)
Use verbs for actions that aren’t CRUD (/users/123/reset-password)
Avoid abbreviations unless they’re industry-standard
Prefer consistency over cleverness

If you need a wiki to explain your endpoints, your naming is broken.

‍

2. Stick to the HTTP Basics

Too many teams try to outsmart HTTP. Don’t.

Use the standard verbs:

GET to fetch
POST to create
PUT or PATCH to update
DELETE to remove

No need for POST /getData or GET /createThing. HTTP already gives you semantics—use them.

‍

3. Avoid Deep Nesting

GET /users/123/projects/456/comments/789/tasks
This kind of nesting looks structured—but quickly becomes unreadable, hard to test, and painful to maintain.

Unless the hierarchy truly matters, flatten it:

Use query params or filters
Link resources using IDs, not paths

‍

4. Think in Use Cases, Not Just Data Models

A common mistake: designing APIs like direct database wrappers.

Yes, the data model matters—but the API should reflect how the frontend or client uses the data.

Example:
Instead of forcing 3 requests to get user info, preferences, and subscriptions—offer a GET /users/123/dashboard endpoint that returns everything the UI needs in one go.

Backend is for composition. API is for usability.

‍

5. Versioning and Stability Are Not Optional

Don't break clients with unannounced changes.

Use versioning (/v1/users)
Deprecate gradually
Keep old versions stable unless there’s a critical issue

If your API changes weekly, no one will trust it long-term.

‍

Final Word: Simplicity Wins

The best APIs feel invisible. They just make sense. No surprise responses, no guessing game with endpoints, no need to dig through docs just to get started.

At TLVTech, we treat APIs like products—because every time someone calls your API, it is part of the product.

If you're building something and want your backend to scale without chaos, let’s talk.

‍

Daniel Gorlovetsky

June 27, 2025