I came across this post on X (https://x.com/jahirsheikh8/status/2070849696730607695). Framed as a backend interview question, it said one of the following two API designs "scales much better," and asked which one you would choose. Option A splits resources by path.

GET /users/profile
GET /users/settings
GET /users/orders

Option B, by contrast, hits the same endpoint and specifies the type with a query parameter.

GET /users?type=profile
GET /users?type=settings
GET /users?type=orders

I decided it was A in about a second. But when I peeked at the replies, people were saying "B is far more scalable." Apparently the same word, "scalable," was being used to mean something entirely different. Same word, different dialect.

Scalability, According to Team A

What Team A means by scalability is scalability as API design. Resources are easy to understand, and response types are fixed. OpenAPI specs are easy to write, and SDKs are easy to generate. In short, it's easy to maintain.

For example, one look at GET /users/profile tells you it's an API for fetching the Profile. And as new features arrive, you can simply add them like this. 
GET /users/security
GET /users/preferences
GET /users/notifications

Scalability, According to Team B

The original poster, on the other hand, seems to have been talking about infrastructure. You put a single API Gateway in front and have it sort incoming requests by type. /users?type=profile goes to the Profile Service, /users?type=settings goes to the Settings Service, and so on. The idea is that the entry point, the interface, stays as one, while only the services behind it multiply.

In other words, they mean "scalable" in the sense that you never have to add endpoints. That is, in its own way, a line of reasoning. Heard in the dialect of infrastructure, B's argument does make some sense.

Keep Infrastructure Out of Your Endpoints

To begin with, API stands for Application Programming Interface: an interface for applications to talk to each other. Since it is an interface, API design is part of application design. I believe it should be considered separately from infrastructure design.

Besides, the setup Team B describes can be achieved with A just as well.

/users/profile
/users/settings
/users/orders
It's simple. Have the API Gateway route /users/profile to the Profile Service, /users/settings to the Settings Service, and /users/orders to the Order Service. Splitting services and scaling out are matters independent of URL design. It is not at all the case that A can't scale and B can.

GraphQL at the End of B's Road

That said, push design B far enough and GET /users?type=profile alone stops being enough. Before long, something like this shows up. 
GET /users?type=profile,settings

Or this.

GET /users?type=profile&fields=name,email

This is a design where query parameters specify "what to return." At that point, it's closer to the thinking behind GraphQL than to REST. In GraphQL, the client specifies the data it wants.

query {
  me {
    profile {
      name
    }
    settings {
      theme
    }
  }
}

So the very idea of switching what gets returned via the query leans toward GraphQL. A team that picks B will sooner or later tailor its own somewhat ungainly GraphQL knockoff. If that's where you're headed, you might as well use the real thing from the start.

That's what I ended up thinking about, prompted by a post asking A or B. The most interesting part wasn't which one is right. It was that the same word was being used in two separate senses: scalability as API design, and scalability as infrastructure configuration.

Mix the two together and the discussion will never line up. It's like each side hearing the other's dialect as nothing more than a bad accent.

Personal taste included, if you're designing a REST API, I find A the more natural choice. It clearly separates responsibilities and responses per resource. Speaking the same word doesn't mean talking about the same thing.