The base url and header details such as api token can all be set in the client in an OOP way already[1]
> What happens if the URL changes?
Cool urls don't change. Use configs.
You don't sprinkle URLs throughout your codebase, as the OP apparently assumes one would normally do. You create a single class (or something similar) which abstracts the API calls. If the endpoint changes, you change it in one place.
I honestly don't see how this solution makes this easier. If anything, I feel like it makes things more complicated and harder to understand.
As I mentioned, if the endpoint changes, you change it in one place. Storing your endpoint URLs in an env file is your personal preference, but that's all. Should has no place here.
It doesn't matter whether it's an environmental variable file, a YAML configuration, a JSON file, or a secure remote KV-store. Barring low water marks, it doesn't really matter where you store your configuration—just make sure to store it in one place.
> Cool urls don't change. Use configs.
I also kinda think that for many webapps, the risk of this is somewhat overstated. I've got tons of apps with a few hard-coded URL paths that point at other internal apps that I own. They don't break because I don't randomly remove URL paths from services. When I do need to change something, find-and-replace + an integration test keep me safe 99.99% of the time (and the blast radius from a failure like this is usually very small - obvious 404 error bubbles up immediately the first time someone hits something broken).
That said, I agree that keeping constants like URL paths in configs is a fine idea. I also feel that common sense is required - a tiny webservice which makes a single request to one URL path probably is fine to just hard-code it (and in fact putting all constants into config might be overly obfuscating), but a big app which makes dozens or hundreds of calls obviously benefits from a config-oriented approach
that's how they all start out, don't they?