Consider using domain extension .rest for API based services - etsync
======
etsync
Since your API is not consumer facing, it doesn't have to shine with a .com
and because there's no .api, .rest would work. Originally for restaurants, but
I'd imagine they'd prefer .com for that perceived trust. Thoughts?

~~~
giorgioz
on www.name.com a .rest domain costs 43$ a year which is four times the cost
of a .com domain. Also you might not be able to transfer the .rest domain to
AWS to manage it with AWS Route 53.

A simpler and cheaper approach would be to create a subdomain and/or a subpath

1) api.example.com (SUBDOMAIN)

2) www.example.com/api (SUBPATH)

3) api.example.com/api (SUBDOMAIN AND SUBPATH)

~~~
rumanator
The subdomain approach is the more appropriate because:

* DNS routing

* Can control/fine tune CORS

* Avoid mixing up path routing with other interfaces/services

* It's more coherent (i.e., page served with www.example.com and REST API at api.example.com)

~~~
giorgioz
yes I agress subdomain is definitely better than subpath overall. I personally
use the subdomain AND subpath approach for a api and an api service
(api.example.com/api) This way I have the separate DNS but if I want I can add
the API service as a subpath to www.example.com/api using AWS API Gateway and
avoid an extra round trip call to the DNS and CORS.

