The Way of Enterprise API Utilization – Interview with API Gateway Developer Team
Trend Article
What are the challenges and advantages of enterprise API utilization? In order to get a grasp of the situation, we conducted an interview with Mr. Kato, an API gateway developer. The interviewer is Nakatsugawa from MOONGIFT.
What are the API gateways you planned from 3 years back?
With 10 years having passed since the popularization of Web APIs (hereinafter referred to as “APIs”), there has been a movement in these past few years among businesses to increase the competitiveness and utilization rates of services by making APIs open. We at NTT Communications have also API-tized our services and are trying to promote their use. Rather than creating a separate API for each service, API gateways refer to attempts to provide an easy-to-use API that standardizes them and unifies management. A number of similar services have become available in these past one or two years.
We planned it about 3 years ago when we carried out a technical verification and launched the project, and it became an officially released service from April this year. The actual development period was only about 6 months as we had made some progress beforehand on technical verification.
API management services already starting overseas
Carriers such as AT&T and Verizon are already starting. There are three primary reasons why carriers are making progress.
- They have a wide range of services
- Customer loyalty is improved by providing these services through a common interface
- It serves as a technical cushion for a wide range of sectors
As an example of problems that can arise when there is no API management mechanism – although this was not APIs – there was a period at NTT Communications during which each department developed smartphone applications freely without any company standards. As a result, there was no sense of uniformity among interfaces and overall quality, which was confusing for users. In order to prevent similar problems from occurring with APIs, we thought of 2 measures.
- API gateways
- API checklists
API checklists define how APIs are to be develop, rather than just develop them.
APIs can be made so long as you have the technical capabilities. However, how to best make them is where differences of opinion arise among the people involved. It is for this reason that we created an API checklist as a unified standard for things such as interface, security, data format, etc.. One point that we were particularly careful about was to use JSON Schema that enables automation or JSON format schema check, a lightweight format based on REST API rather than SOAP. By sticking to these guidelines, we believe that we can create APIs that our clients have no problems with.
※ Please refer to the following article for more on API checklists (Japanese articles).
Things that should be kept in mind in order to design a proper API:
API provision with regard to enterprise can be thought of as the opening up of in-house systems. As there are user limitations in conventional business systems, it is not too much of a problem even when services were temporarily suspended for things such as maintenance. However, as API-tization of these systems means they will be used for automation from outside, things such as down time and information freshness can become a problem. Taking these points into consideration, and as it needed to be system development, we felt that there was a need to change our way of thinking through a fixed framework.
Public was not enough. What was the next step after that?
Although many APIs have been made over the past 10 years, there are many cases in which they were simply made and abandoned. In order to prevent this, we believe there is a need for:
- A presentation of a mash-up example using third-party API
- Applications, tools, and sample codes that use API
We are currently thinking of enhancing libraries and mechanisms that support such developments.
One thing we often hear from developers who are trying to develop using APIs in reality is that they find it difficult to get a sense of scale. The reality is that the sense of scale varies with the application being made, therefore, we want engineers to train their senses by first writing small lines of code using APIs. Our model is that, instead of trying to tackle a large project from the start, it is best to start off small and slowly work your way up to larger projects.
What is the model you aim for with API gateways?
First of all, the API-tization of NTT Communications's services is only the first step. For the next step, we are thinking of API-tizing the services of our client companies and engaging in their management and operation. However, as we are now at the stage where we are promoting API-tization in regard to networks and cloud, all in all, we are still at 20%-30%.
Additionally, we are also focusing on the IoT market. For example, we believe that API gateways can serve as hubs that stand between IoT devices and developers. Data, threshold values, etc. gathered from devices will be available to the public through the API. Moreover, there are also plans to introduce mechanisms that push information both ways using things such as WebHooks and WebSockets.
About 2 years ago, APIs were still at a stage where developers were just starting to get a feel for it. After that, from about last year, the importance of APIs started to be acknowledged, even in the executives. We want to spread the idea that, although it takes time to add an API to an existing service, effects can be increased 2-3 fold while development costs can be kept at 1.1 to 1.2 fold by preparing “API First” from the beginning when developing a new service.
That being said, enterprise API utilization still has a long way to go. To address this issue, we, as ourselves and regardless of our relation to NTT Communications, are planning Enterprise APIs Hack-Nights in order to boost enterprise API utilization and make it more exciting. We hold these events regularly so please feel free to participate!
