5 Things Every Product Manager Should Know When It Comes To Develop A Successful API: Part 2
Dependencies And Infrastructure
About this series
In the next 5 articles, you will learn best practices in developing public APIs and how to take the first steps on this path.
Each article goes through one of the main topics in developing these interfaces. These are the topics that you will get access to:
- First steps and what to outsource
- Dependencies and infrastructure → This One
- Product mindset in API development → 18/10 at The Technical PM’s Newsletter
- Business model and growth
- How to write documentation for an API
Subscribe to The Technical PM to receive articles firsthand. They will be posted there before they come here to Medium.
The Technical PM
The Technical PM is a newsletter for you who are looking to develop technically in product management and expand yourself further.
We will send you materials and tips to help you grow your career for FREE.
Link to subscribe: https://thetechpm.substack.com/
Dependencies
When it comes to public APIs development, you need to understand that you are building a product as well as a platform service.
The concept of dependency that we are going to deal with refers to the need for a feature to exist in order for another feature to be available. In other words, before feature A can exist, I need to build feature B first.
We can understand a dependency relationship that may exist during the process of developing a public API using a company that provides financial market services.
If you wanted to outsource the service of buying and selling assets, you would need to deliver it together with another financial market data collection service.
Because how would users be able to buy an asset without knowing its price?
This might be a simple example, but in several cases, you may enter a scenario where to develop a certain service in the API you will need several others that serve as a base for this one
Due to these types of dependencies, in the first moment, it may be a better approach to think of features that are more independent. That is, they can deliver value without the need to be tied together.
In the example above, first developing an endpoint to deliver market data and then building the functionality to buy and sell ends up being more viable than trying to build both together.
Simpler Use Cases
Also, bringing more uncomplicated use cases into the application can reduce the chances that dependencies are required. In the example of a financial company, understanding less complex scenarios can help in this selection process.
Some scenarios that your company has may have business rules that are too complex to be developed in a programming interface.
In these cases, restricting the application to the simplest and most feasible cases will allow your team to focus more on more comprehensive and less specific deliverables.
Infrastructure
When we talk about infrastructure in API development, we are referring to all the necessary background for the application to work as expected. These are virtual machines, tables, clusters, and other cloud services.
In this article, we will not talk about which services should be contracted from AWS or anything like that. We will focus on understanding what this parallel infrastructure would be in the context of the product.
Passing on information
In most cases, the development of APIs comes from the opportunity to outsource existing services through a public application.
So, the company already provides those services through a platform and sees the creation of an API to provide those services as a way to get more users and, consequently, more revenue.
The engineering teams often build APIs as a kind of proxy.
In computer networking, a proxy server is a server application that acts as an intermediary between a client requesting a resource and the server providing that resource. Wikipedia
A public API is an interface between what the users need and what the internal infrastructure already has.
You can see this kind of approach as a way to use what has already been developed internally to meet the needs of the application. The engineering team understands how to do this pass-through and how the requests should be made to the application.
It is worth pointing out that the internal services of your company were not necessarily built with the vision of being outsourced. This way, in some cases your API will consult some services to execute only one action on that particular endpoint, for example.
Some bullet points about this kind of approach:
- Speed in the development of new endpoints, since the discovery process, will be reduced.
- Think about scaling your API without compromising your platform, once they will be using the same services.
- Security is important, do not allow your internal endpoints to be accessed by your API in any way.
Also, understanding the product concepts applied to API development is extremely significant to understand how to apply these use cases.
But this is a topic for our next talk.
See you in the next chapter.