Source – techtarget.com
when it comes to working with microservices applications. Let’s look at three API design principles to follow when implementing APIs for microservices.
There are three principal people who are responsible for the API design strategy: the business leader, the enterprise architect and the developer.
An API design strategy begins with business leaders, who are in a unique position to see what business needs can be met by expanding the reach of an application. They may want to venture into untapped markets, partner with complementary applications or enable new monetization opportunities. All of these cases rely on APIs.
In the next step, enterprise architects or IT managers will be responsible for implementing the API design according to business objectives. This is where microservices come into the picture. Enterprise architects have an understanding of what the transition from monolith to microservices entails. With this understanding, the chief concern is the security of data that may be exposed. They also care about building scalable APIs that can keep up with the new proliferation of services. Initially, they may choose to spin out just a few services from the monolith, but eventually, they may end up with tens or hundreds of services that make up the entirety of applications. Each of these services needs to be exposed via an API in a secure way.
While all three roles are important to implementing an API design strategy, enterprise architects is in a pivotal role in that they ensure both the business and technology requirements are met.
Understand the three types of APIs
As you plan your API design strategy, keep in mind which developers are building applications that will access your APIs and who the end users of those applications would be. There are three types of APIs based on who has access to them: public, private and restricted. And one of these three API design principles is to understand what each of these types entails.
Private APIs are consumed internally within a company. They are accessed by developers internally and are used by employees. Integrations among customer relationship management systems, ERP systems and intranet sites use these APIs.
Restricted APIs are those that are shared with partners or a group of developers externally but are not available publicly over the internet. An example of this type of API is Hotels.com, a hotel booking website, making its hotel room rates and availability accessible by TripAdvisor, a travel aggregator website.
Use API mashups for a rich user experience
The final of these three API design principles has to do with user experience design. For the richest user experience, you need to leverage multiple APIs in your applications. For consumer applications, this could mean pulling in data from many publicly available data sources, like Wikipedia, YouTube or Twitter. For enterprise applications, this could mean layering information from different applications to get a 360-degree view of the customer. For example, you could create a customer profile that pulls all emails, calls, purchase history and demographic data about a customer and brings it in one place. This could really help to empower support teams, sales teams and other customer-facing teams.
Final note
Microservices applications are all about enabling outstanding experiences for end users. While these are just three of many API principles to follow, by having an API design strategy team, planning how to share your APIs and mashing up multiple APIs, you can cash in on the promise of microservices. Remember, APIs are the key to implementing great microservices applications.
