I have an application that is beiong split out into a number of services. From a previous question on here, I think that initially JSON/REST is the way to go for communication.
Some of my micro services need to be available publicly, for 3rd parties to use.
So I am now wondering about the best way of structuring this. I can see 2 different structures, each with pro's and cons.
- Each Service has its own domain and web service layer, so I could have
- All the services sit behind a common web service layer, so I have;
Option 1 gives a better reduction of dependencies, and maintainability, but at the cost of needing to manage many more domains, and if a 3rd party needs to access several different services, then they need to store and manage several different url's
Option 2 obviously makes maintenance and development harder, as the whole web layer needs to be updated if a new method to any api is added, and the web layer then takes on knowledge of marshalling calls to each specific service. But option 2 also centralises logging, security service error handling and so on. It also means that we (and our 3rd parties) only have a single domain to worry about.
So my question is; for those of you that have gone down this road, which option did you chose, and did you regret it?