use .io or similar for any customer facing websites but a .com for any mission critical api type calls. Customer never even has to know about the existence of myUglyCompanyNameApiHandler.com but all api calls are handled by it.
It's a good idea, but if your product is a website, cookies and authentication in general are going to be a real challenge. Obviously you won't be able to share cookies between the site and the api. But you have the additional challenge of having your api domain treated as 3rd party and are thus subject to all the security measures and sandboxing that come with that.
And what if your product is just an api for use by developers? Now the api is part of your brand.
> Obviously you won't be able to share cookies between the site and the api.
I don't know of any API that requires cookies from the site. Usually you use an access token or something similar for an API.
> But you have the additional challenge of having your api domain treated as 3rd party and are thus subject to all the security measures and sandboxing that come with that.
CORS solves most of the pain points. You just need to ensure the API is serving the correct CORS headers.
sure its not optimal but the lack of available .com domain names forces you into a corner at least in the particular situation referenced by OP.
The other poster is correct though in that CORS will handle alot of your issues.
You are absolutely right in that it is definitely going to increase the effort involved in rolling out a site/service. I don't know of any pretty solution to the issue.
