The company I work for maintains a successful SaaS product that grew "organically" over the years. We are planning to expand the line with a suite of new products that will share data with the existing product. To support this, we are looking to consolidate business logic into a single place: a web service layer. The WS layer will be used by:
- The web applications
- A tool to import data
- A tool to integrate with other client software (not an API per se)
We also want to create an API that can be used by our customers that are capable of using it to create their own integrations. We are struggling with the following question:
Should the internal API (aka the WS layer) and the external API be one in the same, with security and permission settings to control what can be done by who, or should they be two separate applications where the external API just calls the internal API like any other application? So far in our debate it seems that separating them may be more secure, but will add overhead.
What have others done in a similar situation?
Best Answer
It is always good to eat your own dogfood. One API should also be simpler to maintain than two, even if you factor in some overhead for authentication and authorization.