devopsy.kinsta.cloud

Tag: API

  • Digital Business Transformation Driving More API Adoption

    Digital Business Transformation Driving More API Adoption

    A global annual survey of 2,200 developers published today by RapidAPI, a provider of an application programming interface (API) hub, finds digital business transformation initiatives have led to an increase in reliance on external-facing APIs.

    According to the survey results, nearly three-quarters of developers (74%) are using APIs for internal applications. However, nearly half (49%) said they are working on third-party APIs, with 44% working on partner-facing APIs. That’s up from 35% a year ago.

    RapidAPI CEO Iddo Gino said it’s clear APIs are a key enabling technology for driving digital business transformation initiatives.

    More than three-quarters of developers (75%) indicated that participating in the API economy is a top priority for their organization now or in the near future, according to the survey results. Companies are realizing the opportunity for new revenue streams, with growth in API monetization strategies increasing to 41% from 35% in 2020.

    In addition, more than two-thirds of developers (68%) said they expect to increase API use in 2022, with 61% relying on APIs more in 2021 than in 2020.

    However, well over half (56%) noted that a shortage of developer talent is a top concern, followed by lack of internal prioritization around digital transformation efforts (34%), lack of API development resources and tools (32%) and lack of alignment with other departments (29%). A full 90% also noted that security and data privacy is a key issue to consider when employing APIs.

    The results also show the use of REST and SOAP APIs in production environments fell 3.7% and 1.4%, respectively, in 2021. That drop reflects the rise of alternative API technologies such as GraphQL and Async APIs, said Gino, However, he noted it’s unlikely any new class of APIs is likely to supplant legacy APIs anytime soon; instead, most organizations will be employing a wide range of APIs for many years to come.

    The survey results reveal that JavaScript is the most used (71.6%) and preferred (51.9%) programming language for building APIs. TypeScript is also gaining traction in terms of usage (20%) and being preferred (12%).

    The most troubling aspect of the survey, however, may be the fact that well over half of respondents (56%) said they are open to switching jobs. The top five reasons developers said they might switch jobs are higher compensation or improved benefits (60%), interest in a specific product or technology at a different company (54%), desire for a more flexible working environment (38%), interest in a specific company or market (25%) and an opportunity to work with former teammates or friends (17%).

    It’s not clear to what degree the so-called Great Resignation phenomenon might be impacting DevOps teams in general. However, it’s apparent no class of jobs is immune from a general sense of restlessness that pervades the market as the global economy continues to recover from the COVID-19 pandemic. The challenge and the opportunity for DevOps leaders is to encourage the best talent available to join and then remain with their organization versus pursuing a job somewhere else that, at least from afar, appears to have greener pastures.

  • API Sprawl a Looming Threat to Digital Economy

    API Sprawl a Looming Threat to Digital Economy

    New estimates say the total number of public and private APIs in use is approaching a whopping 200 million. APIs are becoming increasingly crucial to the global digital economy. They are the backbone of many digital platforms and drive the composable enterprise model. But this ubiquity presents sprawl issues.

    F5 recently released a study that examines the conditions of the API economy at large. Authored by Rajesh Narayanan and Mike Wiley of F5, the paper, Continual API Sprawl: Challenges and Opportunities in an API Driven Economy, articulates the state of API sprawl and the conditions behind its arrival.

    According to Narayanan and Wiley, “If data is the new oil, then APIs will become the new plastic.” This looming reality will require a continuous approach to API management to avoid further polluting the digital ecosystem.

    Below, I’ll review the report’s main takeaways to see what has given rise to API sprawl and consider how IT leaders should respond.

    State of API Growth

    APIs have evolved as a standard mechanism for businesses and services to connect and share value. And, as more companies begin to rely on them, the API economy is becoming big business—83% of organizations today consider API integration a critical part of their business strategy, according to the 2020 Cloud Elements State of API Integration Report.

    There is a proliferation of API styles. Thousands of public productized APIs exist, but more private and partner APIs are in use. Technically speaking, APIs come in many different forms—they may be web-based, browser-based or embedded into devices. The report also identifies single-purpose APIs and those that aggregate multiple data providers.

    API use cases are pervasive, from hotel bookings to weather, stock tickers, transportation, IoT, DevOps workflows and many other areas. “API-powered apps have permeated every aspect of our lives,” said the report. Yet, typical market estimates are usually quite conservative when sizing up this market, said F5. According to F5’s aggressive calculations, we will be approaching 1.7 billion active APIs by 2030.

    APIs present a high value from startup use cases to enterprise applications. However, a downside is that this growth is leading to sprawl, said Narayanan and Wiley.

    API sprawl is the term used to describe both the exponentially large number of APIs being created and the physical spread of the distributed infrastructure locations where the APIs are deployed.

    Factors Driving API Sprawl

    Sheer growth. Sources predict the number of developers will grow to 45 million by 2030. SlashData also estimates that 30% of developers already use APIs. As the number of APIs on the market moves into the millions, managing growth poses a significant challenge, especially without proper governance and best practices.

    Lack of standards. “The lack of a common shared model contributes to API sprawl,” the report said. API design standards do exist, yet guidelines often leave room for nuances between services. Standards have also emerged around specific industries, like financial data exchange (FDX). While helpful for a single sector, this doesn’t advance multiple industries simultaneously. A lack of standardization leads to differing versioning approaches and integration challenges.

    New development approaches. Integration requirements are forcing many new APIs to unite disparate business apps. The microservices architecture trend is also adding to sprawl, as “APIs are both northbound to interfaces via microservices and horizontally between microservices.”

    Continuous software development. Continuous development, paired with the need to connect business units with bespoke requirements, could produce multiple versions of the same API. This quickly leads to maintenance difficulties, out-of-date documentation and broken clients. The report also cites rising data creation and “everything-as-a-service” trends as harbingers of an API sprawl.

    Various computing evolutions. New computing trends are also prompting a sprawl, says the report. Business units may be operating on different on-premises or cloud environments. When this hybrid situation occurs, APIs could get dispersed over many locations and become difficult to track. Specific connections may be created to cater to new environments like edge computing and IoT devices, further increasing sprawl.

    Problems With API Sprawl

    A digital economy reliant on APIs also relies on the underlying stability and availability of these services. Yet, “APIs have a shelf life and become unsupported if ignored by the developers,” the paper acknowledged. It could be hard to maintain service reliability for APIs sprawled across a distributed cloud. In addition to reliability issues, there are many other possible repercussions of an API sprawl.

    For one, management and operation at scale become difficult. Not all APIs are based on a specification, like OpenAPI. This means that API documentation may not be as streamlined and accessible, thus hurting discoverability and onboarding. “A simple means to connect these APIs may not be possible with conventional or legacy networking approaches,” the report added.

    As developers are top consumers of APIs, a sprawl could negatively impact their integration experience. Maintaining a swelling library of API dependencies can be cumbersome. Plus, APIs are prone to evolve and version over time and when endpoints are altered without advance notice, it leads to broken clients. Even small changes in API functionality can have a huge impact since all observable API behaviors will become relied upon, whether documented or not. (This is known as Hyrum’s Law).

    But the security ramifications of API sprawl are perhaps the most troubling. A whopping 91% of enterprises experienced an API security incident in 2020. Malicious API traffic also rose by a staggering 300% in mid-2021, Salt Labs found. Increased API use will undoubtedly cause more frequent attacks.

    “Unmanaged API sprawl is a security breach waiting to happen,” said the report. APIs typically adopt API keys for authentication and authorization, but this method is prone to misuse. Credentials are often exposed or misconfigured. Bad actors can use APIs to steal loads of data and computing power. As a result, sprawl is undermining trust in API connections and responses.

    Mitigating The Sprawl

    With the growth of the API economy slated to reach the billion mark in the next ten years, figuring out secure, stable inter-cluster communication will become more critical. According to F5, existing solutions (gateways, ingress controllers, service mesh and forward and reverse proxies) are not an adequate response.

    “We believe the solution should hence involve an intermediary (proxy) device focused on solving inter-cluster connectivity, security and integration challenges.” The writers call this solution API Gateway 2.0, which they describe as a bi-directional application-level proxy. The technology exists to implement such middleware and perhaps it could help companies address sprawl issues.

    Outside of Narayanan’s and Wiley’s recommendations, there are plenty of actions API owners can take to avoid adding to the sprawl. Here are a few:

    • Treat the API as a product
    • Improve developer experience
    • Use spec-driven development
    • Ensure up-to-date documentation and code libraries
    • Use consistent endpoint naming
    • Set clear guidelines for versioning and deprecation
    • Go beyond API keys with OAuth and OpenID Connect

    For more context, check out Continual API Sprawl: Challenges and Opportunities in an API Driven Economy for free without an email gate here.

  • Akamai Brings Web Application and API Security Together

    Akamai Brings Web Application and API Security Together

    Akamai Technologies, Inc. this week launched a service that consolidates the process of securing both web applications and application programming interfaces (APIs).

    Amol Mathur, vice president of product management and strategy for Akamai, said with the launch of App & API Protector the managed security services provider is making it easier for IT teams to embrace DevSecOps best practices via a converged web application and API (WAAP) service rather than using separate tools and services to secure them individually.

    The service is also designed to continuously discover API requests that are then automatically inspected for malicious code. Optional API security controls can be enforced based on policies defined by internal IT teams.

    In addition, the company provides access to a multidimensional threat scoring model, dubbed Adaptive, that combines data collected by Akamai with data and metadata from each web and API request to help organizations better understand which threats require immediate attention. Security events are also continuously analyzed using machine learning algorithms to deliver highly accurate policy-by-policy tuning recommendations that can be implemented via a single click.

    Akamai security researchers also make use of machine learning and data mining techniques to continuously analyze over 303TB of daily attack data that is used to automatically update protections. Alternatively, organizations can opt to manually evaluate that data themselves to minimize any unexpected impacts those updates might have on their applications.

    Other capabilities include built-in bot mitigation tools that are informed by a directory of more than 1,500 known bots, integrations with the Akamai command-line interface (CLI), Terraform or scripts used to drive automated pipelines spanning a continuous integration/continuous delivery (CI/CD) platform.

    Akamai

    A recent report published by Akamai found that between January 2020 and June 2021 there were more than 11 billion total attempted attacks made over an 18-month period. The most common attack vector was SQL injection (SQLi) at 6 billion attacks, followed by local file inclusion (LFI) with 3.3 billion attacks and cross-site scripting (XSS) with 1.019 billion attacks.

    The report also found credential stuffing attacks reached more than one billion attacks and peaked between January 2021 and May 2021. Distributed denial-of-service (DDoS) attacks reached a peak of 90 in January of 2021.

    Akamai has been making a case for outsourcing the management of web application and API security via the content delivery network (CDN) it created. Its CDN provides a layer of isolation between web-facing applications and the rest of the enterprise. The challenge organizations now routinely face is that, as they move to deploy cloud-native applications based on microservices, responsibility for security has become more decentralized. The security services provided by Akamai create an opportunity to better manage application security via a single pane of glass at a time when there is more focus than ever on securing software supply chains, said Mathur.

    It’s not clear to what degree organizations are going to rely more on managed security services as part of a larger effort to embrace DevSecOps best practices. However, at a time when application security expertise is hard to come by, it’s becoming apparent that, in many instances, relying on an external service provider to secure application environments is the simplest way to quickly improve the overall security posture of any organization.

  • Salt Security Adds Support for GraphQL APIs

    Salt Security Adds Support for GraphQL APIs

    Salt Security has extended its platform for securing application programming interfaces (APIs) to include support for APIs built using GraphQL.

    GraphQL is an open source data query and manipulation language for APIs that was originally developed by Facebook. It provides a more efficient approach to querying data than the REST APIs that are widely used today.

    Elad Koren, chief product officer for Salt Security, said adding support for GraphQL alongside existing support for REST APIs to the Salt Security API Protection platform will make it possible for security teams to discover those APIs, mitigate data exposure, stop attacks and eliminate vulnerabilities. The Salt platform parses the complex structure of each GraphQL query to identify unique object entities that are then used to create a complete inventory of the GraphQL APIs being employed.

    APIs built using GraphQL are more challenging to secure because of the unique call and response formats, noted Koren. Cybercriminals can also, for example, leverage GraphQL capabilities such as nested queries and query batching, to launch distributed denial of service (DDoS) attacks, he said.

    Many developers will tend to assume that, because GraphQL is relatively new, most cybercriminals are primarily focused on exploiting REST APIs. However, as more developers employ GraphQL, it’s only a matter of time before cybercriminals begin to find ways to exploit APIs that may not be as secure as the REST APIs that many organizations already know how to secure.

    The Salt Security platform itself is based on a big data engine that employs machine learning algorithms and other forms of artificial intelligence (AI) to identify attacks in real-time. It creates a baseline to identify legitimate system behavior while preventing cybercriminals from using penetration testing tools to perform reconnaissance.

    From a DevOps perspective, the Salt Security API Protection Platform integrates with tools such as Jira and Slack to ensure that remediation details are routed to the right development team in addition to helping track tickets to ensure remediation fixes are implemented. It also can be integrated with security information event management (SIEM) platforms from vendors such as Splunk and Sumo Logic to enable incident response for both DevSecOps and security operations teams.

    Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight. However, there will soon be enough APIs based on GraphQL to warrant additional security measures. Less clear is to what degree those security measures will be put in place by DevSecOps teams versus a security operations team.

    One way or another, however, the number of APIs that need to be secured is accelerating rapidly as organizations roll out a new generation of microservices-based applications that drive mission-critical digital business transformation initiatives. Each microservice has its own API that needs to be built and then secured. Unfortunately, most APIs are built by developers that don’t always have the greatest appreciation for security. As such, while more responsibility for API security is shifting left toward developers, many security teams would be well advised to make certain every API being deployed is fully secure.

  • HashiCorp Previews Updates to Consul Service Mesh

    HashiCorp Previews Updates to Consul Service Mesh

    During an online HashiConf Global conference, HashiCorp today made available a beta of an update to its open source Consul service mesh for virtual machines and Kubernetes clusters that makes it possible for multiple administrators to share the same instance of a multitenant service mesh.

    Version 1.11 of Consul will also add support for a command line interface (CLI) for Kubernetes that will provide an alternative to Helm charts for installing Consul on those clusters.

    Raymond Austin, director of product marketing for HashiCorp, said it’s become apparent that there is a need for a higher level of abstraction for managing application programming interfaces (APIs) that is easy to deploy across both legacy IT environments based on virtual machines and cloud-native environments based on Kubernetes clusters.

    Of course, in many cases, those Kubernetes clusters are deployed on top of virtual machines. However, there are also now more instances of Kubernetes being deployed on bare metal platforms at, for example, the network edge.

    As IT environments become more complex, a service mesh makes it simpler to discover, access and secure APIs that are now rapidly proliferating across the enterprise. That transition requires a more dynamic approach to not only managing APIs but also the network services those APIs depend on, added Austin.

    HashiCorp is betting that many IT organizations will prefer to rely on a lightweight open source platform supported by a single vendor rather than relying on more complex open source service mesh offerings being developed under the auspices of a consortium.

    It’s still not quite clear who within an IT organization is assuming responsibility for deploying a service mesh. Most often, it’s a development team that makes the initial decision. However, as IT operations teams become more aware that service meshes represent a capability that needs to be horizontally made available across multiple applications, it may be only a matter of time before some organizations decide to standardize on a single service mesh to reduce operational overhead, noted Austin.

    Service meshes will also play a critical role in simplifying management of networking and security services at a higher level of abstraction within a larger DevOps workflow.

    It’s still early days as far as service mesh adoption in the enterprise is concerned, but there are already a large number of service mesh options. In fact, there may never be a single dominant service mesh platform. Interoperability standards still need to be ratified that enable organizations that have standardized on different service meshes to apply policies to microservices spanning hybrid cloud computing environments.

    Of course, not every IT organization requires a service mesh yet, either. Many IT teams can still get by using a traditional proxy server or an API gateway until the number of microservices-based applications deployed starts to achieve critical mass. One way or another, however, the more APIs there are to manage, the more inevitable it becomes that an IT team will deploy a service mesh.

  • Mastering API Gateways for the Modern Cloud-Native Enterprise

    Mastering API Gateways for the Modern Cloud-Native Enterprise

    As modern enterprises continue migrating to the cloud and the need for connected applications and devices dramatically increases, API-driven architectures are being widely adopted. In addition to the convenience of being able to efficiently connect and share resources, organizations benefit from the innovation and accelerated development speed that APIs bring in multi-cloud environments. APIs are not new, but as more enterprises adopt modern application architectures, they are increasingly occupying a large amount of a software development team’s delivery efforts. 

    When enterprises modernize and migrate to the cloud, it’s natural that challenges arise which need to be tackled before they become pain points—especially when it involves a complex microservices environment. API gateways are an essential ingredient that helps businesses overcome many of the challenges associated with APIs. API gateways are deployed at the edge of an infrastructure, responsible for routing client API requests to backend microservices. Modern API gateways also come with additional perks organizations can benefit from as teams and infrastructure grow simultaneously. 

    Let’s take an in-depth look at some of the major challenges organizations face around APIs, and how to maximize their benefits.

    Rapid Adoption Meets Growing Pains

    API-oriented architectures greatly accelerate the agility of an IT department, as they’ve become a well-known pattern for modern application architectures. However, this approach can be deceptive, as many critical issues and concerns around APIs aren’t always apparent from the onset. If they are not properly identified, they become growing pains teams have to face on a daily basis.

    The first challenge is the need to authenticate users when they make requests. API gateways allow organizations to integrate and consolidate authentication providers using their protocol(s) of choice. With billing and analytics, organizations need to understand the number of resources consumed when processing a transaction and how their customers consume their APIs. API gateways become the natural point at which to collect this data. 

    In terms of DevOps initiatives, some API gateways use service discovery to configure themselves dynamically which greatly accelerates a development and ops team’s velocity when shipping new features or fixes. To help teams deliver a highly available and resilient platform, API gateways are enablers that provide them with the puzzle pieces for advanced load balancing, rate-limiting, circuit-breakers, mirroring and more. These components make the DevOps mindset a reality. Teams can scale them as needed to realize production-grade environments, continuously updating deployments with software changes and avoiding any unintentional single points of failure (SPOFs). 

    In recent years, the evolution of API gateways has solved growing pains in the cloud, helping organizations leverage cloud-native technologies and workflows. Combining cloud-native technologies with an API-led integration platform creates an effective architecture for a digital enterprise to increase productivity. Automating production, operation and services is no longer a goal but a must-have.

    Modern API gateways features within this environment go well beyond what one would expect at first glance. API gateways can be the cornerstone of a deployment strategy transformation. With hundreds—if not thousands—of services to continuously deploy, the risk of introducing a regression to the platform soars, and being able to address this problem immediately is not enough. API gateways can help you transition to modern deployment strategies and blue/green or canary deployment becomes commonplace—helping deployments become an easily managed daily task.  

    API Gateways to the Rescue for Cloud-Native Architectures

    As part of the shift to modern application architectures, enterprises should invest resources in implementing API strategies as part of their software development initiatives. In turn, they should leverage API gateways to alleviate growing pains and simplify delivery efforts. APIs should be secured, managed, observed and even monetized. 

    API gateways can also help with critical issues related to authentication, security and SSL, billing and analytics, life cycle management, high availability and resilience, and they can even help you initiate a culture shift toward a DevOps mindset. By combining API-driven architectures and cloud-native technologies, organizations emerge with an effective architecture for the digital era. API gateways help overcome the challenges and unfold the networking intricacies of today’s cloud-centered world.

  • Hasura Extends Scope of GraphQL API Platform

    Hasura Extends Scope of GraphQL API Platform

    During its online an HasuraCon ’21 conference, Hasura today announced that it has made it possible for developers to employ GraphQL application programming interface (APIs) to launch queries against data residing in multiple databases.

    At the same time, Hasura announced a preview of schema sharing capabilities along with support for workflows based on GitOps processes that it will make generally available later this year. The Hasura Cloud platform can now deploy local migrations from staging to production with a simple git push in addition to accessing previews of applications on every pull request to the git repository.

    The schema sharing capability added to the Hasura GraphQL Engine is intended to bridge the gap between beginner and power users by allowing them to share and install samples of permissions, relationships and metadata. In addition to improving collaboration, the goal is to make it easier to onboard software engineers as projects evolve and become more complex.

    Originally developed by Facebook, GraphQL has emerged as a popular alternative to REST APIs because it enables developers to retrieve data at a more granular level, which results in improved performance.

    Hasura is a provider of an instance of a GraphQL engine the company has developed around a project that is now hosted by the GraphQL Foundation, an arm of the Linux Foundation. The GraphQL Foundation counts among its members Airbnb, Amazon Web Services (AWS), Apollo, Coursera, Elementl, Facebook, GitHub, IBM, Intuit Hasura, Paypal, Prisma, Shopify and Twitter.

    GraphQL provides a complete description of the data made available via an API and is organized in terms of types and fields rather than traditional endpoints. In addition to clarifying what data is available via that API, developers can employ types to avoid writing manual parsing code.

    Since last summer, Hasura has been making available a pilot of a GraphQL implementation that is capable of supporting remote joins across disparate databases. That capability is critical because data sets that are related to a specific business process may wind up being stored in multiple databases.

    Hasura

    Tanmai Gopal, Hasura CEO, said the open source Hasura GraphQL Engine has already been downloaded more than 250 million times this year. Downloads in 2020 reached 100 million. The challenge is that while GraphQL offers a superior alternative to REST APIs, most of the API tooling that exists within organizations is still designed around REST APIs, noted Gopal.

    To accommodate that reality, Hasura has made a tool available that will convert a query designed using GraphQL into a set of calls that are compatible with REST APIs. Developers still gain the benefits of being able to launch more granular queries, noted Gopal.

    REST APIs, in general, are becoming more problematic as organizations embrace microservices-based applications. It often takes minutes to refresh a simple dashboard because of the amount of data that REST APIs are trying to pull from various data sources. As organizations embrace digital business transformation, they are also encountering application latency issues that can be traced back to the amount of data being called from multiple microservices.

    Hasura says in addition to providing a more efficient method to access data, Hasura is also working on adding caching capabilities to its core engine to further improve performance.

    It’s not clear at what rate GraphQL might replace REST APIs, but DevOps teams should assume organizations will wind up employing a mix of both for years to come. The challenge is going to be determining when to make the transition as organizations become more dependent on APIs.

  • Akamai Adds Service to Optimize API Traffic

    Akamai Adds Service to Optimize API Traffic

    Akamai today launched an API Acceleration service specifically designed to accelerate application programming interface (API) calls using special purpose hardware, reserved capacity and prioritized routing.

    At the same time, the company is also making available a globally distributed key-value store dubbed EdgeKV that enables stateful applications to be deployed on its EdgeWorker nodes.

    Finally, Akamai is also making available free tiers of services that provide access to a combined 60 million serverless EdgeWorker events per month with a limit of up to 30 million EdgeWorker events per tier. The two tiers are made up of a basic compute service for applications requiring lower CPU and memory consumption and a dynamic compute service for those applications demanding additional resources.

    Josh Johnson, an enterprise architect for Akamai, said Akamai is expanding its offering at a time when many organizations are starting to deploy microservices-based applications across an extended enterprise using serverless EdgeWorker nodes deployed at the network edge. EdgeKV provides access to a low latency data store that also enables those edge computing applications to process data closer to the point where it is being created and consumed.

    In general, Akamai reported that, in 2020, its platforms processed more than 300 trillion API requests, a 53% year-over-year increase. Much of the increased activity is being driven by distributed applications that are deployed directly on the Akamai CDN, rather than being deployed in a local data center to take advantage of a global network of data centers that allow IT organizations to take advantage of caching. In effect, the CDN becomes the target platform when an application developed using DevOps best practices is being deployed. The rise of edge computing has increased the number of use cases where DevOps teams are relying on CDNs to deploy applications.

    Naturally, competition among providers of CDNs has increased considerably as the number of applications deployed at the edge continues to increase. There may even come a day when there are more applications deployed at the network edge than there are in the cloud as more organization deploy applications that need to process and analyze data in near-real time as part of a larger digital business transformation initiative.

    Akamai, of course, as the provider of the largest global CDN, is betting it will be able to leverage the size of its CDN to convince developers to deploy applications on its platforms rather than smaller rivals.

    Regardless of the approach to edge computing, the applications being deployed will be more latency sensitive than ever. Each IT organization will need to decide to what degree they want to count on infrastructure to optimize API calls those applications make before they time out or need to be redirected to another microservice. One way or another, the laws of physics still apply. No edge computing application is an island. It depends on a complex web of infrastructure ranging from routers and switches to servers running back end services in the cloud. The challenge is finding a way to optimize all those interactions in a way that developers never have to be concerned about.

  • Why API Quality Is Top Priority for Developers

    Why API Quality Is Top Priority for Developers

    It is no secret that web APIs have become increasingly important to the operation of modern businesses. According to RapidAPI’s Developer Survey and Insights report, 61% of developers used more APIs in 2020 than 2019, with 71% planning to use even more in 2021. We are no longer tied to a small number of monolithic service providers. Businesses tend to gravitate toward specialized managed services, such as billing and authentication, which are backed by APIs. Business models for new products and services are constructed based on APIs. Trust has become a necessity for APIs. APIs that perform consistently and with high quality earn trust, and those that do not are abandoned for a competitor.

    Why Does Quality Matter?

    If a market exists for an API, it’s a given that there will be competition. To remain competitive, APIs must build and maintain trust with their consumers; sales and marketing can only go so far. The highest quality APIs will inevitably capture the largest slice of market share. Quality isn’t a destination, either—it is a collection of goals that require continuous investment.

    What Does Quality Mean for an API?

    Just like the code that drives an API, the quality of an API itself is quantifiable. The following facets describe some broad categories used to measure API quality. The weight of each facet will vary depending on how business-critical the API will be when in production.

    Resilient. An API is resilient when it continues to operate in the face of adverse conditions. Can an API continue to operate (even at reduced capacity) if the database is down? How does it handle network traffic spikes?

    Robust. A robust API is liberal in what it accepts, but conservative in what it sends. Will it crash when presented with a poorly formatted request, or respond with instructions on how the caller can fix the problem themselves? Can the code be restructured without breaking the API contract?

    Secure. API security is vital in most deployments. Are efforts made to check for OWASP Top 10 Web App security risks? Are open source vulnerabilities known and addressed in a timely manner? Are secure endpoints gated with authentication?

    Discoverable. APIs that are well documented and well structured are much easier to consume and integrate with other services.

    Consistent. A consistent API is one that changes without negatively impacting existing consumers. Changes are backward compatible or versioned as new features are introduced. API consumers should know far in advance if a breaking change will be coming if it cannot be avoided.

    How Do I Get There?

    Processes, tools and, most importantly, culture, are the key to high-quality APIs. Let’s explore how we can approach each API quality facet.

    Resilient. Processes such as chaos engineering, load testing and manual quality assurance can uncover situations where an API is failing to handle unexpected situations. Deploying your API to a cloud provider with a compelling SLA instead of your own hardware and network shifts the burden of infrastructure resiliency to a service, freeing your time to build features for your customers.

    Robust. A comprehensive suite of automated tests isn’t always sufficient to provide a robust API. Edge cases, unexpected code branches and other unplanned behavior may be triggered by requests that were not considered when writing the test suite. Traditional automated tests should be complimented by fuzz testing to help uncover hidden execution paths. Canary and blue-green deployments can further expose your API to the real world in a limited manner and prepare for when even more unexpected requests will hit.

    Secure. API security is a moving target. It is expected that most APIs are built on layers of open source libraries and frameworks. Software composition analysis is a necessity to stay on top of zero-day vulnerabilities by identifying vulnerable dependencies as soon as they are discovered. OWASP guidance is a must-have—directing API developers to implement attack mitigation strategies such as CORS and CSRF protection. Application logic must be well tested for authorization and authentication.

    Discoverable. For REST APIs, the OpenAPI initiative provides a consistent language for describing the API. Many frameworks, such as Spring Boot, can even generate OpenAPI documentation directly from your code. gRPC-based APIs offer similar benefits by providing both instructions for accessing the API and building the clients to communicate with it. Adding support for GraphQL allows developers to connect multiple APIs together with consistent tooling. Whichever direction you choose, it is vital to keep API documentation up to date and accessible.

    Consistent. To be consistent, the API development process should make incompatible changes obvious. Code reviews can catch many breaking changes right at the source. API contract testing and integration testing can be used to discover API changes as part of the build. When working in a microservices environment, staging environments may alert engineers if an API change will cause problems before production.

    Quality Builds Trust

    According to the RapidAPI survey, 58% of executives said participating in the API economy was a top priority for their organization. The figure was even higher in certain industries such as telecommunications, where the number is 89%. Whether you are building APIs for internal use or for public consumption, your goal should be to earn the trust of API consumers. Investing in the culture, tools and processes to build quality APIs will pave the way to building and maintaining that trust.

  • API Security by Design

    API Security by Design

    “APIs are nothing new,” said Secure Code Warrior co-founder and CTO Matias Madou, but they have recently become more widely used.

    And where they were once a local mechanism, they are increasingly used in a distributed manner, partly because of changes to application architectures. Another reason is that users are increasingly likely to access systems from outside the organization, whether they are customers, suppliers or employees working at home.

    Potentially anyone and anything can access an API, so developers and architects should therefore assume that APIs are exposed, and treat requests accordingly.

    This means addressing issues such as authentication and authorization, and generally ensuring that the only data exposed by the API is the data that’s supposed to be exposed.

    So assume every API call is malicious, suggested Madou.

    Start at the Beginning

    Achieving API security starts with the design and architecture, so jumping in and writing code immediately is a mistake. Unfortunately, starting with a completely blank slate is unusual, and some code will likely already exist. In that case, it is especially important that the design makes provisions for possible weaknesses.

    If you want secure APIs, then ensure that everyone working on the project – architects, developers, testers and so on – are “very security savvy,” said Madou.

    The need to improve skills is often triggered when the company or one of its competitors experiences a problem.

    So teams should work to identify any existing problems, realize they need to proactively avoid the underlying issues, and undergo appropriate training, he says.

    The trouble is, “security and developers are not often the best of friends,” Madou said. So, developers tend to think that security is the responsibility of their security colleagues. But there should be a common goal: making reliable and secure software.

    “Security needs to help developers,” he said. One way of achieving this is to appoint a ‘security champion’ to act as a bridge between the security and development teams. An embedded security person can help developers realize that security is an enabler, not a blocker.

    Help When Help’s Needed

    Embedding communication from the security team into developers’ workflows is another part of the process. Slack is one possible conduit. Security people need to be wherever developers discuss issues. Then, they can take advantage of opportunities to say things like, “it looks like you’re having problems with SQL injection. Here’s some training material that might help.”

    Developers live in their IDE, so that’s where integration should occur. But design such systems to help developers, not to control them. “Developers are people, not robots controlled by machines,” Madou warned.

    Another consideration is that it’s important to avoid unnecessarily interrupting developers. Such systems should therefore predict what a developer is about to do and deliver appropriate guidance.

    For example, if someone codes a database connection, the system could offer the statements that securely retrieve information. Then, the developer can copy and paste them instead of starting from scratch each time. Using new code every time carries the risk of introducing vulnerabilities.

    “It’s tricky to make these systems,” Madou admited, but he predicted they will become increasingly common in the coming years.