What WEB API structure do you use in your projects: api.site.ru or site.ru/api/?

Question

API

1. What WEB API structure do you use in your projects?
2. Which option do you think is the best and why?
3. Which option is better for SEO (if it is better?)
4. Select from the list below the most preferred API option for a link like: moscow.site.ru/products/

api.moscow.site.ru/products/
api.site.ru/products/
moscow.site.ru/api/products/
site.ru/api/products/

UPD. api executes, not an application, but a website
Thank you

Answer 1

1. api.site.ru
2. Yes, it's just more convenient.
3. Does not affect, sort of like
4. api.site.ru/products/ but moscow can already be solved at the level of parameters or
PS sessions. If you need to use the API on the site, then in the case of api.site.ru, you can simply proxy from site.ru/api/ to api.site.ru

Answer 2

The choice is made based not on the beauty of the sound, but on whether api.site.ru and site.ru are physically one installation of the application or two.
If two domains have the same code base, and only the logic at the request routing level differs, then there is no point in bothering with subdomains.
Cons of subdomains:
Separate subdomains are a separate browser request to DNS. This time.
If your entire application runs on SSL (and you will have to switch to it when you want to see referrers in Google Analytics statistics) - you will need separate certificates for subdomains, or a wildcard certificate.
And if the subdomains work on SSL, then the browser will make an additional handshake to exchange keys with each subdomain.
If subdomains are managed manually and you have to change hosting, then you will get tired of moving your hands.
Why is there a substitution of the third or fourth level to some site?
Because maybe they have duplicated API servers geographically to distribute the load.
You can ping each subdomain and make sure that they will most likely have different IPs.
Selected automatically or otherwise based on the user's location.
The API domain address has almost no effect on SEO. Almost - this is because Googlebot counts the time from the request to the server to the moment the entire page is rendered, including loading styles, fonts, JS scripts, loading data and rendering the page in its virtual browser. If we take into account the points above, then it will take time to establish a connection and a handshake. By indirect signs, slow sites have a higher position in the search results, that is, further from the first place. But where the data on the page came from, Googlebot doesn’t give a damn.
But sometimes you have to sacrifice speed on DNS resolve and SSL handshake, and make subdomains if you need to issue a lot of data at a time. For example, if there are a lot of pictures on the page, the browser will try to load them at the same time. The browser has a limit on the number of competitive requests per domain, it seems = 6. That is, until 6 images are loaded (site.ru/img/1.jpg, ...), javascript will not be able to access data on the same domain site.ru/api.
Options:
1. transfer all statics (styles, pictures, scripts) to the static.site.ru subdomain - let the statics blunt in separate requests; and javascript and css should be loaded first
2. allocate api.site.ru subdomain for api
I usually do the first option, but it all depends on the load.
Example: websiteicons8.com , the API runs on the api.icons8.com
domain and is an independent application, static is returned through maxcdn.icons8.com they will have one left api.icons8.com
To reduce the time for DNS resolve, we use Amazon DNS - it seems to be the fastest. Well, MaxCDN also uses Amazon and in general the loss is almost not felt.
Time measurements were made through the www.webpagetest.org utility - a cool service, just gold.

Answer 3

If the API runs a separate application, then it can be in a subdomain.
api.site.ru/products/moscow/