Generally it's considered best practice for a web site to only actually serve its content under one domain name, and have any other alias names only redirect to that one canonical domain name.
However, that redirect is an HTTP concept, not a DNS one. A CNAME record does not redirect anything, it just makes it so that one name resolves the same as another name in DNS.
The normal approach would be to have a web server facilitate the redirect directly in the HTTP response headers (through web server configuration, or done by the application handling the request if applicable); by sending HTTP status 301 (or in some contexts 302) with a Location header.
As for other variations on achieving redirection in a browser, one could serve HTML with meta refresh or possibly even Javascript as you suggested. That will however run the risk that some less browser-like HTTP clients will not follow the redirect.
Also, unless it serves a purpose, I would suggest that it's probably better to not actually have both these names even point to the same site in the first place, but instead have a separate site dedicated to redirect handling to avoid any confusion.
As for API clients, that one more or less takes doing things right in the first place to avoid having people start using the different names at all, because if they do you may not be able to fix it on your end without outright breaking those clients.
Ie, document which URL should be used, and either have no API available at all under the other name(s) or have those redirect just to make it clear where the API actually is. Just don't expect the API clients to actually follow redirects, because they likely won't.
