Our application is based on an API first architecture and is currently based on a single domain / service:
api.todos.com
Consumers of the API are :
We will be building new micro-services written in different languages for the same application. For example we might develop API services for:
My question is around dealing with domains. Would it be best to split each service into a different subdomain e.g.
api.todos.comstats.todos.comcontent.todos.comrss.todos.comsearch.todos.comOr is it better to have a single unified API domain where we do HTTP (layer 7) routing to reach our endpoints. e.g.
api.todos.com/todosapi.todos.com/statsapi.todos.com/contentapi.todos.com/rssapi.todos.com/searchNot sure which is preferable for a public API? It would be easier to have multiple sub-domains and not have to deal with an intermediate routing layer / proxy.
As System Architect I think it is better to have a single unified API domain where we do HTTP (layer 7) routing to reach our endpoints. You can make your system more flexible without any changes for your clients. For example you have a microservice with routes:
In future you can split the microservice by this routes.
But mostly, it depends on what API Gateway will you use. API gateway is single entry point in your system, what proxy request to correct microservice. Also it make auth and cache. More about this microservice's pattern you can read here.