[xnorswap]

I always thought it was bad practice to use the same domain for API and non-API traffic. In the browser there'll be a ton of wasted context (cookies) attached to the API request that isn't needed.

So it's better to have "api.example.com" and "www.example.com" kept separate, rather than using "www.example.com/api/", where API requests will have inflated headers.

[andrewaylett]

That very much depends on what's hitting your API and why. If it's browser clients, you might want to worry about headers and cookies -- but with http/2 and http/3 using hpack and qpack you should be able to avoid sending all the data each time. If the clients aren't browsers then the question is moot but there are other reasons to consider.

In any case, I'd recommend same-origin requests for browser access to APIs and a separate domain for non-browser access, purely for separation of concerns. That lets you tailor the access rules for your endpoints according to the type of caller you're expecting.

[wichert]

What matters is that there is nothing listening on port 80 on the same IP address. That may be hard to control if you are using an environment with shared ingress.