API design – splitting into different sub-domains (micro-services)

Our application is based on an API first architecture and is currently based on a single domain / service:

api.todos.com

  • Deploy Java EE application to payara41 docker container using maven
  • Set ports for container in docker for docker-client for java
  • Jenkins Docker container not copying pre-installed plugins to JENKINS_HOME on start
  • Docker, referencing a differnet container. Call mysqldump using php command
  • Need to install Perl AND Linux
  • Docker: Give container user write access to host directory
  • Consumers of the API are :

    • Our web-frontend
    • Our mobile-apps
    • Other business / public

    We will be building new micro-services written in different languages for the same application. For example we might develop API services for:

    • Statistics
    • Blog / Content
    • RSS Feed
    • Search

    My question is around dealing with domains. Would it be best to split each service into a different subdomain e.g.

    • api.todos.com
    • stats.todos.com
    • content.todos.com
    • rss.todos.com
    • search.todos.com

    Or 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/todos
    • api.todos.com/stats
    • api.todos.com/content
    • api.todos.com/rss
    • api.todos.com/search

    Not 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.

  • Docker - set DNS from inside container - for VPN?
  • How to reduce docker image size?
  • Restcomm RVD is not running from docker container
  • Add a volume to Docker, but exclude a sub-folder
  • Application served by uWSGI with Supervisord from Docker
  • Access named volume from container when not running as root?
  • One Solution collect form web for “API design – splitting into different sub-domains (micro-services)”

    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:

    • api.todos.com/route1
    • api.todos.com/route2

    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.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.