Core API

With the virtualization and tools to automate deployments it appears easier to think modular architecture that allow reusing of software modules. Deploying peace of software on a VM don’t cost a lot and with virtualization it cost less on infrastructure to manage small VM that run at 50% occasionally than a big one that work at 10% full time. Using API to allow each module to communicate with each other is a good idea.

The idea with Core API type is to separate the job of the module (its API) and its implementation (the language or framework use to code the API).

So on agile development you can start your service with an implementation of the Core Module that allow fast evolution with perhaps poor performance, and change the implementation later keeping the defined API and so no need to change components that use them.

The other idea with Core API, it is that is quite easy to define reusable API that you need on most projects. So you can create a catalogue of API with various implementations that you can share with all your projects. But as the module is still own by the project, it keeps the control of the management of the module.

As the Core API module is only used by the project, no need to implement hard security mechanism to allow components to communicate together.

Service API

Several clients (server component or application) could use simultaneously a Service API. A service API is designed to serve multiple clients. They don’t only shared the API definition or the implementation like for a Core API; but they also share the servers. That could look simple but that change a lot of stuff.

You have for example to manage security to ensure that one client can’t access the “private” data of another. You also have to manage how a client subscribe or unsubscribe to the API Service.

  • As it serve multiple clients, the roadmap of the service can’t be manage anymore to fit only the needs of one of the client.
  • If the API evolves, you have to ensure with the entire clients that the transition will have not break their services.
  • You will have to provide a support team to help your clients solving their issues.

As soon as you expose an API to several clients you have to manage it as an independent services. If you don’t do it you will quickly have major issues that could make your projects die.

But creating a service cost resources. You have to identify how your API service will create value for your enterprise to ensure that building this service is good investment.

If you design your service to help several internal projects to reduce their cost; perhaps you have to ask you what is the better solution:

  • Creating an API Service to share resources.
  • Creating a Core API to share design and development.

If you not sure the service is a good idea, the Core API is less dangerous and need less investment.

If it’s for external clients, as for other services you have to check there is enough business to generate profits with it.

Presentation API

If you speak to API Ayatollahs it is probably the worst type of API. Presentation API is dedicated to one client application to expose the API it needs to display information. It is build on top of one or several Service API. The main goal of Presentation API is to limit network exchange between the application and the server to enhance performance. It also allows masking Service API to allow accepting change on API Service without having to update client application on Google or Apple store.

When your application use only one Service API, presentation API could seems useless. But if you build your application on top of several Service API; it could be useful to aggregate them behind a Presentation API.

A presentation API have to be able to change with the application; if you share it with different project it become a Service API with all its constraints.

Conclusion

When you create a Service and you want to know if it’s a god idea to expose part of your API to other; start to ask you if the API itself is a Service or a Core or a proxy dedicated for your application. If you decide to expose it as a Service, check that you have the resources for that. If you decide to expose it as a Core, check that you don’t share your main expertise with your competitors. If you have a presentation API, keep it for you.