DZone Research: API Management Issues
The most common issue affecting API management is the lack of attention to security or thinking APIs can be secured like applications.
Join the DZone community and get the full member experience.Join For Free
To gather insights on the current and future state of API management, we talked to 17 executives who are using APIs in their own organization, as well as helping clients use APIs to accelerate their digital transformation and the development of quality applications. We asked them "What are the most common issues you see affecting API management?"
Here's what they told us:
- 1) Where APIs are becoming more prevalent, there is a problem of how to manage. Provide APIs to deliver status or monitoring information. 2) Security is an issue. Need to abide by security standards and follow standards set by Google for APIs, SSO, RESTful.
- 1) On the technical side, it should be easy, but a lot of people don’t know who their audience is for an API, external/internal. Think of the API as a product and different people as users of the product. The process of being a product manager. API as a product. 2) The process of putting authentication in place with OAuth or OpenID easy to make a mistake. More libraries and tooling the better. Do not implement from scratch.
- Security space in general in 2001-2 anyone with a web app is special. No app is built without the internet in mind. Building an app without an API-first perspective. API security is rarely a part of application security. APIs have become mostly HTTP-based REST.
- Lack of scoped access. No all or nothing. Lack of logging. Mitigating against denial of service. APIs that cause downstream effects and can plug phones with messages and poor UX. Breaking SLAs. Hard financial costs.
- Within API management, it is still challenging to enable self-service of APIs and to expose the security model to external partners. Self-service APIs enable users — both internal and external — to find the right API, understand how it works and start using it quickly and easily. API management can take care of things like throttling and rate limiting. But today, tasks like self-service application registration are processes which still need to be built.
- Ignoring the data. API management means creating and managing without thinking about the developer experience. Developers want their lives to be made easier. Vendors are not thinking about that. World of APIs has enjoyed rapid growth because of lightweight standards as growing up in an API based world we are beginning to see standards in different verticals like healthcare and banking. Don’t prescribe a solution, must have X, Y, and Z. Standards could make this easier.
- People don’t know what APIs can do. So many knowledge gaps on what APIs can do for you. They want to get on the bandwagon without knowing where to start. Understand corporate culture, frameworks, knowledge. Debate REST versus SOAP versus what am I trying to achieve with the API. 2) Lack of a consumer-focused approach – design and documentation are important. Build for scalability and sustainability built for the long run. Service will keep multiplying in backend applications. Best practices for design and documentation, associated with the right owner easily catalogs and discovered. 3) Monetization of APIs product strategy.
- On the user side, it’s been less dynamic in terms of what you get is what you have to use. Today more dynamic APIs and ability to extend the APIs this has opened up for companies that do want to integrate more transactional, trigger-based, webhook integrations. Some applications can integrate applications quickly where there are no off the shelf integrations. We’re seeing more flexibility to connect, automate, orchestrate through dynamic APIs.
- The most common issues are around the lack of proper consumer-driven API design early on. When the API design comes too much from the provider’s perspective it can lead to project failure. Another common issue is the lack of automated testing, leading to poor quality and breaking changes when releasing new revisions of the API, potentially disrupting the business processes of the organization itself or its partners.
Lack of Standards
- 1) Versioning, a lot of strong opinions. Challenging whether to do the right thing and there are different opinions about the right and wrong way. Need to know what’s best for you and your customers. Had to deprecate some functionality endpoints but benefits outweigh rolling out a new version of the API and then support, monitor and customers migrate. Simple but clear standards on what’s a good and bad change. Can’t do anything to break the customers’ integration. 2) Having good standards. Multiple teams developing and deploying. Well documented standards. Keep them simple and have a good code review process. People and process problems. A lot of great technology that can be leveraged, but don’t overlook business processes.
Clients want to modernize and go to edge with microservices but run into issues getting started from old-style machine interfaces. How does the journey begin and how do you break things down? 2) In edge architecture, the ability to figure out all of the endpoints your system will touch — RFID in retail, what are the assets in the aisle is an API chain. Deployment and application development must go hand in hand. How will you operate and use?
- Paradigm shift API as an infrastructure and this concept of breaking things into discrete chunks leads to a mindset have to get over. Customers want end-to-end loan origination but the industry moving away from that. People responsible for IT infrastructure not prepared to be in control of their own destiny. The proliferation of APIs and people don’t know what the APIs are doing.
- Level of API maturity in the organization. A lot are in the initial stages. The concept of application development for integration is not well understood. From a developer’s perspective, they can get trapped into exploring all services as APIs and end up with API sprawl. Start with the value of API talking about API design.
- Many of the players in the APIM space often fall short of providing capabilities in all areas needed for a successful API program: 1) across the entire API lifecycle; 2) fulfilling the functional needs both of IT and the business user; and, 3) using APIM as part of a broader integration capabilities set. The third may be the most important because enterprises don’t simply need a portal for public APIs. That is table stakes these days. Thought-leading enterprises need a single view of all API traffic and performance, whether public, private, or partner APIs; they need to be able to manage and govern APIs from conception, to scale, to sunset.
- Many API Management offerings treat APIs as an entirely separate portion of the overall Software Development Lifecycle (SDLC). This means that businesses trying to adopt DevOps practices in their application development often have to step out of those automated processes to manage the policies around their APIs in an entirely separate fashion. API Management infrastructure and services should be able to play well with existing tools for application development, deployment, and monitoring, and should become a seamless part of the overall application lifecycle.
Here's who we talked to:
Opinions expressed by DZone contributors are their own.