You are designing APIs for a platform with a web app, a mobile app, internal service-to-service traffic and third-party partners. What do you expose, and where?

What the interviewer is testing

Whether you choose per constraint or adopt one technology as an identity. The wrong answers here are all defensible-sounding and all wrong for the same reason.

The reasoning, per audience

Internal service-to-service → gRPC. Binary encoding, HTTP/2 multiplexing, generated clients, and a .proto file that is a machine-checked contract with explicit backward-compatibility rules. Nobody is exploring these endpoints with curl, so the discoverability cost does not apply.

Mobile and web → a BFF, or GraphQL if the graph is genuinely rich. These two clients want different payload shapes and evolve on different cadences — mobile especially, because old app versions live in the wild for years and you cannot force an upgrade. A BFF per client gives each team control of its own contract. GraphQL is the alternative when the clients are numerous and diverse and the data is a genuine graph; it costs you HTTP caching and requires depth limiting and persisted queries to be safe.

Third-party partners → REST, with OpenAPI. This is the one place where the answer is unambiguous. Partners want something they can explore with curl, read documentation for, and call from any language without a toolchain. REST plus a published OpenAPI spec is the lowest-friction integration surface there is, and friction here directly costs partner adoption.

Why the other options fail

GraphQL for everything puts a query language in front of partners who wanted three endpoints, and puts a resolver layer in the path of internal calls that need microseconds.

REST everywhere is not wrong, just uniformly mediocre — chatty for mobile, slower than necessary internally, and with contract enforcement left to discipline.

gRPC internal, REST external is close, and it is the answer that misses the mobile and web distinction. Those are external, and one REST API will not serve both well.

What a strong answer adds

• The external contract is the expensive one. Internal protocols can change; a partner API is a commitment measured in years. Version it deliberately from day one.
• Every audience gets the same compatibility discipline regardless of protocol: additive changes only, contract tests or schema-registry enforcement in CI, and a deprecation policy with notice periods.
• The gateway does authentication, rate limiting and routing for all of them, so the policy is uniform even where the protocols are not.