Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

DZone Research: API Management for Devs

DZone's Guide to

DZone Research: API Management for Devs

When managing APIs, developers need to think about security, purpose, and the end user.

· Integration Zone ·
Free Resource

Discover how you can get APIs and microservices to work at true enterprise scale.

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 do developers need to keep in mind when managing APIs?"

Here's what they told us:

Security

  • Be aware of the security implications. Be really thinking more like distributed systems engineers. Participating in a mesh of distributed systems. Keep the three layers separated so you can trace your work. Include identity — when, where, and how long it ran.
  • Think about security. A key does not equal security. Credentials can be stolen. APIs are not under attack any less need same level of security thought as you put in your site. Hackers probe all access points.
  • Architecture. Secure design pattern training, integrating the security tools and services you have into the SDLC. Software composition analysis tool in line. Moving right in staging environment run dynamic security test against your API. Make sure you have continuous security monitoring.
  • API security of more important than general web app security. The API will be used for things you cannot predict and be prepared to address that.

Purpose

  • Understand your use case and going for the most elegant solution. Evaluate build versus buy. Know what you want the CX to be and focus on the technology solutions you want to provide. Think about the purpose of your API. 
  • Simple is better. If you go back to scorecard-as-a-service as an example discrete value on the number of variables that can be entered I return a score. Keep APIs very specific and very simple.

End User

  • Think about the consumer of the API. Are you developing an API that’s fit for purpose? We’ve gone beyond one size fits all. Now APIs are becoming more focused on a particular solution. Customize API for the use case and think about security from the beginning.
  • You want good feedback from the developer community on the value API is providing. Must return value to the business or the digital transformation team. Apiary lets you do testing early on to get a feel for what the outcome will be. REST JSON in skillset, the language of choice JavaScript or Groovy. 
  • Make it thorough. Methods names event properties should follow standards so other developers can see and understand the scope of the API. 
  • 1) Have a design first 2) consumer-focused mindset, 3) documentation, 4) shift left, test and QC early on; 5) virtualization for acceleration. Have backend and frontend to build and scale applications. Reduces interdependencies. 
  • 1) Non-technical have an API on something people care about. People will use the API if they care about the data or the system behind it. Find users to talk to about what methods they prefer. Expose useful stuff. 2) A technical look at Open API Initiative (Swagger), API specification language of choice. openAPI.org start there to educate yourself. 
  • APIs can be used for purposes that are very different from what was originally envisioned. It’s important for developers to design not just for what they need now, but with other application needs in mind. It’s a balancing act. You don’t want to design for the world — don’t over-engineer; but at the same time, people might find uses other than what was originally expected. It is critical for developers to be responsive to their consumers and users. In some ways, you have to treat API like its own product with its own life cycle. Use cases are going to change, but maybe that can feed back into the application or uncover additional functionalities that users need. If developers can be flexible enough to do this, there is an opportunity to turn that into an additional revenue stream. 
  • Some of the most important considerations around APIs aren’t technical in nature, but rather business-related. Before embarking on an API program, it’s important to understand the value of existing data and applications, an appropriate business model with which to capitalize on that value, and how a successful API program will change current Go to Market approaches. Will the APIs be internal or external? Who are my consumers? How would they like to consume my APIs? Are they intended for innovation, or to support my own mobile or integration initiatives? This is especially true when an API program is accompanied by a fundamental change to how applications are built, such as the adoption of microservices. The shift away from monolithic application development has a massive impact on an organization’s people and culture and requires buy-in across the enterprise. The change management around the design, delivery, and management of applications — and the culture around that process — is just as important as the policies placed on the application interfaces themselves. 
  • First, they always need to keep in mind the other developer who will need to consume this API, and also the developer who will continue to manage the lifecycle of this API when he has moved to another project. APIs tend to create long-lived dependencies with internal and external partners and need to be managed throughout their life cycle. Finally, they need to keep in mind that while taking a code-driven approach to API development and using the latest API frameworks, they also need to think about their overall team’s productivity and ability to scale their work and maintain great consumer experience overtime, including always up-to-date API documentation and self-service onboarding when suitable.

Other

  • 1) The idea of standardization warms my heart. APIs need to be standardized. The need for a central language between two devices. Look how the big guys are doing it and how they name and document things. 2) Documentation. Think about developer experience as a while, signing up, getting code, the little things that make a difference. Revolutions coming in developer experience give error message directly in the API. Don’t waste time looking for.

  • Think about good coding practices. Shared repositories for APIs and related technologies. Not creating our own integration within the organization. History of changes that have been made. Coding practices come in. Platforms have the ability to add users of the APIs to the environment to the API or the platform so only people who have access can make changes to the APIs. Avoid one-off integrations. Good documentation and commenting on the code.
  • There has never been a better time than now for developers to lead the way in their enterprises when it comes to high visibility/high-value digital transformation initiatives. With API’s becoming central to such initiatives and API-led development becoming the norm rather than the exception, it becomes even more important for developers to partner with their business peers on the business value developers are unlocking with their API-led initiatives. To facilitate such collaboration, it’s important to leverage a full lifecycle API platform that can provide business users the right level of control, governance and visibility and developers the full freedom to invent and innovate.

Here's who we talked to:

APIs and microservices are maturing, quickly. Learn what it takes to manage modern APIs and microservices at enterprise scale.

Topics:
api management ,career development ,integration ,apis ,security ,api platform

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}