Loading ...
Techceler...
Technology & Engineering
Integration
45
0
Try Now
Log In
Pricing
<p>2018 State of API Integration Report 1 2018 State of API Integration Report 2 Table of contents A Word from our CEO ........................................................................................................... 03 Meet our Contributors .......................................................................................................... 04 Section 01: Introduction ................................................................................................... 05 Behind the Data .................................................................................................................... 11 The 2018 State of API Integration Survey Respondents ............................................................ 12 Section 02: Trends in API Integration ............................................................................. 13 Building a Platform Strategy .................................................................................................... 15 Drivers of Adoption ................................................................................................................ 19 Customized APIs ................................................................................................................... 20 Strategic Shift of Integration ................................................................................................... 23 Evolution of B2B Integration ................................................................................................... 25 Flexibilty ................................................................................................................................ 26 Longevity .............................................................................................................................. 27 Section 03: Developer API Integration .......................................................................... 29 Emerging API Styles ................................................................................................................ 35 API Security ............................................................................................................................ 39 Interactive Calculator ........................................................................................................ 44 Closing ....................................................................................................................................45 2018 State of API Integration Report 3 A word from our CEO Our Mission is to Integrate App Ecosystems by Unifying the World's APIs. Integration. It's that pesky part of making a product that no company actually wants to do. (And who can blame them? It's not easy.) But it's also the part that really has to be done well. Because if your product can't be used by the people who need it, then why build it in the first place? It goes far beyond a simple connection to an API. Cloud Elements has re-imagined the world of application integration so you and your customers can focus on the data they care about. This report addresses the continued growth in API adoption, where the market is headed with ease of integration, and new trends in the coming year. Happy Integrating. Mark Geene CEO - Cloud Elements @mgeene 2018 State of API Integration Report 4 Meet our Contributors Ross Garrett at Cloud Elements @gssor Ross Garrett is the VP of Marketing at Cloud Elements - responsible for market strategy, product positioning and evangelism. He is a well-known speaker at developer events and other industry conferences. Kin Lane at API Evangelist @kinlane I am the API Evangelist. Not in the sense that I'm evangelizing a single API to you--In the sense that APIs are important for everyone to be aware of. I'm paying attention to not just the technical, but the business and politics of the web API movement. Isabelle Mauny co-founder and CTO of 42Crunch @isamauny Isabelle Mauny, co-founder and CTO of 42Crunch spent most of her career at IBM, across a variety of technical roles, at the European level. She was part of the IBM WebSphere Strategy board and played a key role in the deployment in Europe of flagship products such as the WebSphere Application Server or DataPower appliances. Mark Boyd API industry analyst @mgboydcom Mark Boyd is a writer and API industry analyst, who writes regularly for ProgrammableWeb, and The New Stack. He has chaired several API conferences, and published a number of ebooks on the API lifecycle, best practices for API adoption, and API uptake in industry verticals. 2018 State of API Integration Report 5 Introduction S E C T I O N 1 2018 State of API Integration Report 6 The State of API Integrations As we learned in last year's State of API Integration Report, the fast-paced world of SaaS Applications and app development is nothing without advanced API integration. Not only have APIs become a necessity for application customers to streamline operations across their business and product suite, they have become an integral part of product development, business strategy, and scalability. As a result, customers will continue to seek out applications and APIs that can be easily integrated. It's no longer sufficient to offer a standalone, isolated productdevelopers must build flexible platforms that not only offer highly functional APIs, but also integrate seamlessly to the ecosystem of products and services used by their customers. APIs are the foundation for this network effect, and must continue to evolve to meet the expectations of developers. The role APIs and API-based integration need to play in creating a customer-centric platform is a key theme we discovered in building this year's report. The proliferation of applications and subsequent API-based integration demands that developers now consume and build against a multitude of endpoints, languages and platforms. To develop a top-down view of this rapidly growing network, we surveyed hundreds of application developers for feedback on their own APIs and their experience with others they work with. We've distilled all of that information into the most noteworthy stats, changes and trends in our comprehensive State of API Integration 2018 Report. Not only have APIs become a necessity for application customers to streamline operations across their business and product suite, they have become an integral part of product development, business strategy, and scalability. S E C T I O N 1 Section 01 | Section 02 | Section 03 2018 State of API Integration Report 7 Important Findings: Building Platforms Instead of Products This report will cover key findings from the survey we distributed to collect insights into the state of API integration. It will share our predictions on how these findings will change the industry in 2018 and beyond. We will explore prominent themes, including the expectation that APIs ease integration, rather than stifle it, and that successful applications should be more like platforms than products. For example, 36% of respondents stated that their primary motivation to become a platform provider was sparked by their desire to maintain 'stickiness' with customers by integrating easily across the ecosystem of applications. While most companies "considered themselves a true platform provider," one-third of respondents said they offered pre-built integrations for non-technical users. Without such an option, customers with little-to-no development experience will struggle to build their own workable integration limiting the network effect of that platform. This report helps define what truly constitutes a flexible 'platform,' and the implications that this definition has on the industry. Our data also exposes the growing desire for innovation in event-driven integration: Nearly 40% of those surveyed responded that their apps did not support event-based framework, but it was the number one answer when we asked which API technology area was most in need of innovation. While this architectural pattern is enjoying something of a resurgence - as it reduces coupling between services and provides a far more efficient way of synchronizing and updating data - work still needs to be done amongst API providers to embrace event-driven capabilities. Find even more of these key observations in the following sections! While most companies "considered themselves a true platform provider," one-third of respondents said they offered pre-built integrations for non- technical users. Section 01 | Section 02 | Section 03 34.4% 2018 State of API Integration Report 8 Looking Ahead in the World of APIs The report also gives us an opportunity to look forward to 2018 and beyond, and predict new trends in the API space, including: Connecting to an API, and truly integrating with an API are not the same - developers and API providers alike must consider all aspects of integration and find ways to standardize and simplify this process. Applications should focus on developing 'stickiness' and the ability to easily integrate to other products and partners in order to stay competitive in their markets and drive both new and renewed subscriptions. The continued growth of public APIs that are open to any developer will be paired with pre-built integrations that non- technical consumers can implement easily to streamline processes. Developments will be spurred in particular by verticals like FinTech, Banking, Healthcare and Human Capital Management. Further support for event-based integration, which is a feature commonly requested by developers, but that has commonly been unavailable for apps currently on the market. This introduction serves only as a high-level overview of the results we collected from our State of API Integration survey. Keep reading to get the full breakdown on the current state of the API industry, a look at what's trending and why, and a look ahead to where we believe API integration is headed. Section 01 | Section 02 | Section 03 2018 State of API Integration Report 9 " I've been watching the technology, business, and politics of APIs in a full time capacity since 2010, and the biggest trend I am seeing in 2018 is that it's no longer a conversation about whether or not businesses should be doing APIs. In 2018, it is expected that you need APIs to do business in this digital age. The companies, organizations, institutions, and government agencies who are just beginning to invest in their API infrastructure are quickly realizing how far behind they are when it comes to the efficient delivery of data and content to web and mobile applications, as well as the ability to work with Internet-connected devices, and take advantage of the benefits of machine learning and artificial intelligence. However, the platforms who have been investing in their API platforms for the last couple years are shifting their focus towards increased investment in event-driven architecture, and an API governance strategy to further optimize and maximize on their earlier investments. To be able to operate their platforms at scale, API providers have embraced a microservices-centered, robust lifecycle approach to delivering their APIs, with an OpenAPI-driven definition acting as a central contract. Providing a blueprint for designing, deploying, managing, and properly integrating, and extending each service to wherever it is needed, no matter where that might be. Providing the machine readable gears that are needed for the automation required as part of an ongoing organizational digital transformation. The API Landscape of 2018 Contributed Content from Kin Lane, API Evangelist 2018 State of API Integration Report 10 In 2018, OpenAPI has become the contract for doing business with APIs, and is key to API providers efficiently delivering and managing their growing number of microservices. This contract is being used to manage the platform, but also ensure that services properly reach outwards to API consumers with up to date API documentation, robust SDKs, IDE integration, and API discovery solutions for developers. These contracts are also being used to drive spreadsheet integrations, Salesforce connectors, and the growing number of integration services that have emerged on the landscape to help non-developers take better advantage of API- driven resources. OpenAPI definitions are the technical, as well as business contract for mature API platform providers, allowing them to manage their APIs at scale, and reach a technical as well as business audience. With machine readable contracts in play, driving an increasingly automated lifecycle, API platforms are looking to further refine their API governance strategy, helping ensure the continued delivery of highest quality APIs at scale. When this is combined with a heightened investment in real time streams of information, event-driven infrastructure, and the development of relevant machine learning models, API industry leaders are looking to shift their platforms into high gear. This all makes the conversations around whether or not we should be doing APIs a distant memory, turning hard fought lessons around delivering, integrating, and aggregating APIs into the fuel for the next round of investment in event-driven architecture, machine learning and API governance that will help drive business growth for the next decade. 2018 State of API Integration Report 11 Which industry are you in? While the majority of repondents are technology companies, our metrics represent at least 27 distinct industries Behind the data Technology - 137 Media 7Manufacturing 7Entertainment 7Retail 9Healthcare 9Government 9Transportation 10Education 12Other 43Banking 13Engineering 15Communications 20Consulting 23Finance 36Section 01 | Section 02 | Section 03 Last year, Cloud Elements released the first ever State of API Integration report, which analyzed data from within the Cloud Elements API Integration platform, including over 1.6 billion API calls to 160+ endpoints. We are taking the 2018 report to the next level. This year's report expands upon the data from the Cloud Elements platform, featuring data collected from 400 companies, in 27 distinct industries, with annual revenues ranging from less than $100,000 to over $25 billion. Collectively, these participating companies spent 200,000+ development days building over 4,500 API integrations in 2017. Our inaugural State of API Integration survey was distributed between September 2017 and March 2018 to representatives of these companies. Their responses contributed to the identified trends surrounding the existing demand for API integrations and the roadmap for leveraging integrations in the future. The report also includes industry expert insights from Ross Garrett, VP of Marketing at Cloud Elements, Kin Lane, The API Evangelist, Mark Boyd, writer for The New Stack and ProgrammableWeb, and Isabelle Mauny, co-founder and CTO of 42Crunch. 2018 State of API Integration Report 12 The 2018 State of API Integration Survey Respondents Integrating the World of APIs The analysis in the 2018 State of API Integration report represents data collected from companies across 44 countries and 6 continents 43% CTO 5% CIO 4% Partner 3% Product 2% Sales 2% Marketing 36% Executive 7% Developer What is your position? Section 01 | Section 02 | Section 03 2018 State of API Integration Report 13 Trends in API Integration S E C T I O N 2 2018 State of API Integration Report 14 Trends in API Integration As the number of public and private APIs grow month over month and year over year, it's no surprise that at least 85% of organizations we surveyed consider Web APIs and API-based integration fundamental to their business strategy and continued success. Of these, more than 60% have invested in a public facing API and the surrounding infrastructure to manage access for developers and partners. Building a Platform Strategy: How to drive new revenue opportunities or deliver value through API integration. Strategic Shift of Integration: How API integration has matured to enterprise applications like ERP. Drivers of Adoption: Changing how developers and end-users consume APIs and integration services. Evolution of B2B Integration: Organizations are evolving the way they share and synchronize data with partners. 1 3 4 2 Over 60% agree, API Integration is critical to their business strategy. S E C T I O N 2 2% 0 4% 1 9% 2 24% 3 61% 4 Not at all Critical Section 01 | Section 02 | Section 03 2018 State of API Integration Report 15 Building a Platform Strategy Today's most successful software companies have made the leap from selling products to selling a platform. The appeal of such a move is understandable: software products generate only a single revenue stream, while platforms, by connecting different groups of users and services, can generate multiple revenue streams. Our survey responses demonstrated that more than half of organizations today would consider themselves to offer a platform or to be on the path to offering a platform. Of those that don't, it's important to have a made a conscious decision in this regards - hope is not a strategy, and many product organizations are being disintermediated for moving too slowly in this regard. 1. Single-sided business model limits your company's growth and longevity. You're simply delivering a product in the way that you always have, to the customers you always have, without really thinking about the network around your organization. 2. Multi-Sided Business Models take that a step further. In this model, a platform company enables other businesses to interact with your technology in order to build new services and applications. 3. Third party integration can create greater adhesion, stickiness and relevance across your market. Do you consider your organization a platform provider? Platforms enable a multi-sided business model that can be a key driver of growth: 57% Yes 43% No Section 01 | Section 02 | Section 03 2018 State of API Integration Report 16 Model A Basic Usage Metering This is the most obvious method of generating revenue from your APIdirectly charging for it. This strategy works best if your organization provides access to data or services that people want to pay for. Model B Upselling API Integration SaaS providers use this model often, as customers have become increasingly demanding of integration capabilities for any product they buy. Adding API integration to a subscription offers a strong motivator to upgrade to a higher package, and creates a stickier relationship with customers by allowing end users to customize their experience and workflow more easily. E.g. Dun & Bradstreet is a data provider, and expose data as a service via API. In this case, customers are willing to pay for programmatic access to D&B's services to enable new business processes and products around the D&B platform. E.g. Concur provides pre-built integration options with their product, so that subscribers of the service can easily synchronize expense management data with ecosystem of apps used in their back-office processessuch as accounting and ERP systems. Section 01 | Section 02 | Section 03 2018 State of API Integration Report 17 Model C APIs as a Product APIs that are themselves the product can be the most complex monetization models, but they also often provide the highest valuecollecting some revenue share or service-based fee for the product delivered via API. E.g. Paysimplea leading payment gateway provideroffers API access to their payment services. Customers of this service will then be charged a percentage of the payment amount for each API transaction. Model D Distribute Value through Partners Organizations can scale the reach of their product by integrating their API with strategic partners. This has the potential to open your business to existing application ecosystems which you may not be able to reach alone. E.g. Sage works with various ISVs to distribute their products and services as part of a broader offering. This network effect has enabled them to achieve the scale and growth that would be difficult in a direct sales model. Section 01 | Section 02 | Section 03 2018 State of API Integration Report 18 While these are only examples, each describes a path towards revenue growth and ecosystem expansion with APIs. We expect that leading platform providers will leverage more than one (if not all) of these models as they grow. Ultimately, a move toward "best-of-breed" is on the rise - meaning that every product, in every vertical, is better served by enabling integration to the ecosystem of apps around them rather than remaining a hermetically sealed environment. Over the coming year, we anticipate to see more of the world's successful software companies continue to make the leap from selling products to selling a platform. Model E Improve Operational Efficiency API integration can help you build end-to-end solutions more efficiently. They help you innovate faster, engage customers and partners faster,and perhaps most importantly, they allow you to iterate (and even fail) faster. The time taken to build or automate business processes can easily improve from a couple months to a couple hours, solely because of the efficiency gained from an API integration. E.g. Microstrategya leading business intelligence platform provides pre-built integration to several leading enterprise SaaS applications, so their customers can quickly access and integrate the data they care about without needing to build anything from scratch. Section 01 | Section 02 | Section 03 2018 State of API Integration Report 19 Drivers of Adoption This report paints a picture of hockey stick growth and untold opportunity, but the growth in APIs hasn't come without challenges. Many application providers, businesses and even platform companies reported concerns around API adoption. Issues with API adoption can be related to developer experienceAPI style, documentation, functionality, etc. But the real issue is far more systemic than DX. Adoption is limited by the addressable market, i.e. the number of developers that are available to learn, build against, or even care about your API! Our 2018 survey points to evolving and increasing need in the world of API integration, creating a possibility for non-technical users to build the workflows they need. By offering "no-code" or "low-code" capabilities, we can massively expand the total addressable market for APIs and instantly solve the common adoption concern. How Organizations are Driving API Adoption Today (Respondents selected all that apply) Public API, open to any developer 56% 42% 60% 35% Platform that enables developers to build integrated services Pre-built integrations that non-technical users can leverage SDKs to ensure integration is easy for developers Ease of Use Easiest Section 01 | Section 02 | Section 03 2018 State of API Integration Report 20 Customized APIs One Size Does Not Fit All As API integration evolves and matures, it has become very clear that not all API consumers are created equal. Data objects may need to be modified based on the device type; orchestration or composition may be needed depending on the sophistication of the client; security might need to be adapted to fit mobile, web, or IoT scenarios. The list goes on. What is the highest demand from your customers and partners for API integration? Other 13% 2% 19% 19% 47% Customized APIs that fit a specific business need Better documentation "No Code" integration templates SDK wrappers for APIs they need and use Section 01 | Section 02 | Section 03 2018 State of API Integration Report 21 With each new innovation in connected devices, and each new user and application experience that accompanies these devices, organizations must consider an application architecture and integration strategy that embodies flexibility and agility. API mediation is becoming a more familiar concept as many organizations begin to evolve beyond their first foray into the API Economy. API mediation is a solution for enriching or personalizing interactions between distributed application and service components. We like to call this API Experience Management. The key to the API experience model is placing a new mediation or abstraction layer between API consumers (apps, services, and "things") and API providers (services and applications). This layer wraps the backend API (the inner API) and exposes a personalized and managed API (the outer API) to each defined constituency of consumers, simplifying the developer experience while also ensuring loose coupling. The new outer API may also aim to offer more advanced features to your developers, providing a facade on top of the inner API to enhance its functionality, or simply keep pace with changes across API technologies and best practices. A great example of this diversity comes from Netflix, where their API development team learned quickly that a "one-size-fits-all" approach to API integration wasn't going to work. The team found that different client applications (such as a desktop browser, a mobile application or a smart television) required different functionality as they accessed the Netflix API, thus forcing the API team to build an increasing number of features to address the demands. Once continuously updating this single interface became unmanageable, they introduced an API experience, or mediation, layer on top of their existing API platform that allowed each UI team and even partners to optimize the API experience for their specific app or device. Section 01 | Section 02 | Section 03 2018 State of API Integration Report 22 The burgeoning Low-Code/No-Code space has become an extraordinarily disruptive force in the domain of API integration - causing confusion amongst developers, users and even vendors. But even the terminology itself can be misleading, as the distinction isn't about whether people need to code or not - but rather about the types of people using technology and tools to build API integration Representing the "No-Code" domain are the "citizen integrators"an analyst term to mean business users who can build functional, but perhaps simplistic workflows without having to write a line of code. In the "Low-Code" domain, we focus on developers instead, demanding platforms to help streamline and simplify their workdelivering enterprise-grade API integration without having to start from scratch. Twenty years ago, application integration was implemented by hundreds of consultants and experts at a multi-million dollar cost. Now, with no code/low code, the same integration use cases can be implemented at a fraction of the price and in a fraction of the timeand users expect it. API providers must start to deliver more tooling that expands their addressable market, makes it easier to get started quickly and transfers the burden away from the application buyer. Source: Gartner 2017 Inner APIs Out er APIs Out er APIs Out er APIs Out er APIs Customers Applications Things IT Systems Section 01 | Section 02 | Section 03 2018 State of API Integration Report 23 Strategic Shift of Integration Integration is all about making different apps and systems work together. Allowing them to share data, orchestrating business workflows, and coordinating how users work across growing number of apps. As the app ecosystem developed, it spawned a new world of API-based integration and a landscape of integration platforms aimed at helping developers manage how their applications interact. Now, as API integration matures, the requirements, technology and integration use cases have also matured. Many organizations must now work to integrate both their new SaaS applications and legacy systems in the same developer friendly environment. Integration Needs Comparison Internal Needs within an Organization vs. External Application Needs by End Customers Database 21% internal external 16% ERP 16% internal external 13% Finance 11% internal external 9% Communication 11% internal external 11% Marketing Automation 10% internal external 12% CRM 18% internal external 23% Section 01 | Section 02 | Section 03 2018 State of API Integration Report 24 SaaS has dramatically changed how we purchase, consume and adopt softwaremaking business apps easy to buy, use, and maintain. As a result, application integration has become a differentiating factor of every business, not just a tool. Today, an average enterprise uses 1,181 cloud apps across its entire organization (source: Netskope, Feb 2018). This is a stark contrast to the 1990s, where an average enterprise used 5-10 enterprise apps. API integration is centered around adopting best-of-breed apps and systems by enabling smart, fast, adaptable integrations and automations across all of a company's apps, APIs, data, people and devices to deliver innovative, personalized experiences. For API integration that means the way businesses work has drastically changed from the days when traditional integration tools were created. Business apps have become consumerized, self-service, and low-cost, but the tools to integrate these apps often remain complex, technical, and sometimes more expensive than the apps they are integrating. Integration tools should be flexible, allowing integrations to be changed at any time. In the past, integrations were 'built-to-last'. Once you have your Order-to-cash process going between your SAP and Salesforce, you don't go back to change itthe requirements were more stable. This is no longer the case. Business apps and the processes and workflows around them are constantly changing as new apps are added and existing apps are changed. Constant change is the norm, requiring organizations to think strategicallynot tacticallyabout API integration. In short: traditional integration platforms may be powerful, but they are limited by the apps they support, the number of use cases they support, and who can use these platforms. These limits are the reflected on the entire organization, making it impossible to enable enterprise users to build integrations that support their line of business, to offer embedded integration experiences their customers need, or to build the products their organization needs to survive in the digital era. SaaS has dramatically changed how we purchase, consume and adapt softwaremaking business apps easy to buy, use, and maintain. Section 01 | Section 02 | Section 03 2018 State of API Integration Report 25 While traditional B2B integration via EDI and other similar interfaces is expected to remain a large part of the partner collaboration market for the next few years, API integration technologies are seeing growing adoption across many industries. By migrating to API-centric partner integration, or adding this option to existing business processes, organizations can deliver the same quality of service with much less overhead. APIs offer an easy way for companies to establish these essential integrations with customers and other businesses. There are 2 key areas B2B integration strategy should consider: New Digital Products Being Developed in 2018 Evolution of B2B Integration Businesses are not islands. Connectivity, collaboration, and success with partners and customers is the lifeblood or fuel that drives any organization. Providing a way for these partners to access your products, and exchange information is fundamental. However, many organizations still rely on outdated and outclassed B2B infrastructure to exchange this crucial information. Partner integration in 2018 and beyond requires a different approach. Web APIs not only deliver more flexibility and speed, they will also enable you to attract and connect many more partners and customers than today. During 2018, more than 50% of all B2B collaboration will take place via API integration, and prospective partners will expect that they can integrate with your business via a lightweight API- based approach. This trend is reflected in our survey results, showing that 65% of respondents are developing new B2B products and B2B API integration solutions. 65% B2B products 39% Mobile products 36% B2C / Consumer Products 27% Employee productivity 23% IoT Applications Section 01 | Section 02 | Section 03 2018 State of API Integration Report 26 Flexibility By allowing a multitude of companies to leverage your platform for a variety of use cases, your company can open the door to a larger market segment. Think about how your customers or product teams consume your API. What level of burden are you forcing upon your customers? Would better documentation allow people to integrate with your business better? One of the biggest mistakes you can make is assuming that your API offers all of the utility that every persona might require. In fact, our survey shows that many developers take weeks to complete an integrationand every day spent is lost business value. Average Number of Days to Build Net New API Integrations Section 01 | Section 02 | Section 03 2018 State of API Integration Report 27 Longevity According to Constellation Research, 52% of the Fortune 500 have merged, been acquired, gone bankrupt, or simply fallen off the list since 2000. In order to survive in the API economy, you have to think about longevity. To set yourself up for success, it's important that your organization can support a wide variety of use cases in a dynamic market. The narrower your supported use case, the less likely your company will last in an ever-changing environment. As use cases and needs change it's important that your company has a wide enough lens to adapt in real-time. The best way to widen that lens is learning from the ecosystems and the partners that you do business with. By quickly integrating into multiple application ecosystems you diversify how similar use cases are used in different environments, increasing your stickiness and preserving your longevity in the market. Offering Integrations Leads to More Revenue Majority (64%) agree that at least a quarter of their user base will upgrade or renew, if they offer integrations 64% > 21% 15% 11-20% 13% 6-10% 8% > 5% Section 01 | Section 02 | Section 03 2018 State of API Integration Report 28 Summary API integration is no longer just for developers. Businesses can leverage platforms to drive various competitive advantages and achieve long-term success. It is important to consider how your organization interacts with all segments of your customer base, delivers and consumes value in the surrounding ecosystem, and thinks strategically about integration. S E C T I O N 2 2018 State of API Integration Report 29 Developer API Integration S E C T I O N 3 2018 State of API Integration Report 30 Event-Driven Integration Based on our research, one sentiment is clearmany architects and developers have high interest in and adoption of event-driven integration. Most organizations aim to create their own "Composable Enterprise" and will rely on multiple cloud- based services to deliver this vision. Yet, many of these SaaS applications are islands that haven't been optimized for integration, and many developers depend on pollinglots and lots of pollingto create the workflows and integrated scenarios they need. For many application providers, there is a long way to go before they can offer the features and event-driven capabilities developers expect. Real-time demands are driving event-driven requirements The need forand increased interest inevent-driven architecture is arguably attached to the demand for real-time application integration and data movement. The world of "real-time" is perhaps misunderstood, used in the wrong context or at best an overloaded term where the tolerances for delay or latency vary based on the use case. There can be varying opinions on the definition but in this case, 'real-time' implies web technologies that enable applications to react to relevant business events as they happenor at least within an understood period of latency. (e.g. 4ms delay may render a financial trading platform uncompetitive, while 400ms delay is easily tolerable for most application integration use cases.) S E C T I O N 3 Developer API Integration Today's software architecture draws together a complex web of internal and external services to deliver new value to customers at a lightning pace. Any successful, forward-thinking business today leverages the power of APIs to integrate a wide range of services, data, external providers and internal business capabilities into new workflows, mobile applications, and customer-facing products. However, as application and end-user demands evolve, this architectural approach also comes with challenges. In this section we'll discuss 3 key architectural concerns you should consider when building, integrating or managing your APIs. Section 01 | Section 02 | Section 03 2018 State of API Integration Report 31 Event-driven technology The good news is there are a variety of technology options and architectural best practices available to embrace real-time integration. The WebSockets standard is now well established as an efficient mechanism to stream data in real-time, and Webhooks is gaining momentum as the protocol and pattern of choice for event-driven APIs. The arrival of HTTP 2.0 and Server-Sent Events also represent an ever evolving landscape of technologies that may be used in other event-driven use cases. WebSockets WebSockets provide a richer protocol to perform bidirectional, full- duplex communication. This two-way channel is more attractive for things like games, messaging apps, interactive experiences, and for cases where you need real-time updates in both directions. But again, the solution isn't perfect as the integration pattern effectively breaks the semantics of HTTP. Server-Sent Events First-off, the term Server-Sent Events (SSEs) may be unfamiliar for many. For the past few years the specification has been in a state of flux and overshadowed by the more fully featured communication protocol - WebSockets. However, the idea behind SSEs should be familiar: allowing a Web Application to "subscribe" to data updates originated (sent) by a server, and subsequently be notified as these data events occur. The problem with SSEs is that, while they remove the polling technically, they also take much of the control from the user and forces the user into a passive state. Section 01 | Section 02 | Section 03 2018 State of API Integration Report 32 Over the past 18-24 months there has been increased chatter about the limitations of Web APIs, and how architectural choices must be made on merit versus conceptual elegance. This has led to the evolution of standardssuch as v3.0 of Open API Specification, which now includes a way to document Webhooks as part of a RESTful API. Webhooks Webhooks work by automatically posting new event data to a user- defined URL, which is monitored by the user's linked applications. Each time a new event is posted to the URL, the linked applications update to include the new data. Unlike polling, which delivers usable data on less than two percent of requests, webhooks only update when new information is available. Because of the increased efficiency, over 82 percent of developers surveyed by Wufoo indicated that they would rather receive new data via Webhooks instead of with polling. Despite this preference, our research revealed only 29 percent of APIs currently support webhooks. Developers Prefer Webhooks Over Polling Over 82% of developers surveyed by Wufoo indicated that they would rather receive new data via Webhooks instead of with polling. Despite this preference, our research revealed only 29% of APIs currently support webhooks. Section 01 | Section 02 | Section 03 2018 State of API Integration Report 33 Our Recommendation There is no single design decision that perfectly answers every integration question, but the perils of polling are clear: higher network overhead, increased cost and poor user experience. Our recommendation is to consider alternatives like Webhooks when building your next Web API or integration scenario. One clear signal emitted by the strongest API providers across landscape in 2018 is the importance of investing in event-driven infrastructure, and the development of a real time perspective of getting business done using their API-driven infrastructure. The phrase event-driven will mean different things to different providers, but generally it reflects the ability to respond to internal, partner and consumer needs in real-time, as events around valuable resources occur. Event-driven infrastructure might involve the development of Apache Kafka pipelines within the enterprise, the delivery of financial market data to web and mobile devices using Server-Sent Events (SSE), all the way to pushing data and content via webhooks as resources are added, updated, or even removed via APIs. API infrastructure has historically been centered around making the resources they have available in the web, mobile, and device-based applications. Event-driven API infrastructure is about making sure An Event-Driven API Landscape Driving What Matters To Consumers Contributed Content from Kin Lane, API Evangelist Section 01 | Section 02 | Section 03 2018 State of API Integration Report 34 the most meaningful, valuable, and relevant information is delivered when and where they are needed--driven by API consumer's needs and desires, moving the conversation beyond just what resources API providers have available, and making it about what consumers need. When you watch what the most seasoned, and mature API providers are investing in across the landscape in 2018, you hear stories about Yelp or Pinterest's investment in Kafka infrastructure internally. You also see Stripe, and Slack adding further to the list of webhook events that their API consumers can subscribe to. Event-driven signals are a sign of platform maturity, and that API providers are moving beyond the early stages of their development, having seen the traction and adoption that they were seeking. These providers are now interested in cutting through the noise and distortion, and ensuring that their API consumers are subscribing to and in tune with the most relevant events that are occurring via the platform at any moment. Event-driven architecture isn't just about data firehoses and pipelines, or real-time streams. It is about making sure your platform is pushing beyond the basics of API operations, and is managing and moving around data, while applying algorithms in the most efficient and meaningful way possible. Realizing an event-driven way of doing APIs isn't about the next trend in doing APIs, it means you are mastering the regular aspects of platform operations, and have begun investing in the next stage of its execution, speeding up the delivery of resources, and optimizing their orchestration. Event- driven APIs aren't just about being able to technically deliver in real time, it is about being able to do business in real time, responding to what matters, as it occurs. 2018 State of API Integration Report 35 Emerging API Styles As the API integration landscape evolves, new API styles such as OData and GraphQL are emerging and gaining ground amongst developers. Here we'll evaluate each of these with regards to achieving interoperability across APIs for analytics, integration and data management. What is OData? Originally developed by Microsoft in 2007, OData is an OASIS standard REST API well- established among companies such as Microsoft, SAP, IBM and Salesforce. It allows the creation and consumption of queryable and interoperable RESTful APIs in a simple and standard way. OData gives you a rich set of querying capabilities and is quickly gaining ground for its open source approach, as well as its exceptional scalability. What is REST? REST (representational state transfer) or RESTful web services are one way of providing interoperability between computer systems on the internet. REST-compliant web services allow requesting systems to access and manipulate textual representations of web resources using a uniform and predefined set of stateless operations. RESTful implementations make use of standards such as HTTP, URI, JSON and XML. It's important to note that REST is an architectural style, not a standard. What is GraphQL? Developed internally at Facebook in 2012, before public release in 2015, GraphQL is a data query language deployed at companies such as Facebook, Shopify and Intuit. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need, makes it easier to evolve APIs over time and enables powerful developer tools. Section 01 | Section 02 | Section 03 2018 State of API Integration Report 36 The table above highlights common criteria for accessing data through open standard interfaces. OData has the full range of support for all these query capabilities. You can do some of these operations with GraphQL, but they're not standardized or documented in a way to achieve interoperability. GraphQL is much like REST in that it defines the way to interact with a web service, but it doesn't tell you what the service does. So you can do filtering, ordering, and joins, etc, but the application developer has to understand how those work semantically to be able to know what their behaviors are. API Versioning and Maintenance One key area of maintenance is handling updates to applications when the API changes, while maintaining older versions. The biggest problem leading to this dilemma with REST APIs is that all of the fields are returned when you query an endpoint. API providers have no visibility into whether or not clients are relying on information in specific fields. API consumers must process all of the fields returned even if they do not need the information. GraphQL has addressed the problem of API versioning and maintenance by forcing clients to specify exactly which fields they require. OData provides similar functionality by providing a select list to limit the number of fields returned to those needed by an application. This reduces response size and processing in an application. However, it does not provide a mechanism to indicate that fields are deprecated. Section 01 | Section 02 | Section 03 Query Capabilities: OData vs GraphQL Operations OData GraphQL Filtering Ordering Aggregation Joining Paging 2018 State of API Integration Report 37 GraphQL has already seen rapid adoption since its public release in 2015. Production use cases from enterprise, government and startups are already in place and new tooling continues to evolve and diversify. As an API technology, GraphQL is finding its place in the broader API market landscape and has potential to strengthen adoption by leveraging two other API sectors: in Serverless and in the Internet of Things. While sectors like ecommerce and publishing are already seeing significant value from moving to a GraphQL API architecture, this year is starting to see other industries take notice, particularly online video services. Key early user segments in marketing technology, software development tooling, and digital consultancies will help spread adoption to other industries. One of the key benefits of GraphQLthe ability to create a data abstraction layer that can combine multiple sources through a single gateway and endpointwill garner growing interest from industry sectors that have complex data supply chains. Data science, healthcare, and city services will be drawn to GraphQL in 2018 in the same way that publishing, social media and ecommerce have been to date. GraphQL has quickly established itself as a valid option for businesses and developers making choices around how to create and manage their API strategy. Across the sector, the biggest gap is a matrix decision tool that allows API creators to assess each type of API architecture option and weigh up the best cases each is suited to implementing. Without this clarity, each individual business must do their own research from REST, Hypermedia and HATEOAS, SOAP and GraphQL options. For many use cases, GraphQL has the potential of leapfrogging the growing interest in hypermedia APIs. In hypermedia APIs, responses describe what data and links are available so that as queries are made, an application can discover what other data and capabilities are available that are relevant to the application's need. GraphQL: Changing the Landscape of APIs Contributed Content by Mark Boyd 2018 State of API Integration Report 38 In hypermedia, this requires good metadata and well structured endpoint linking, but can return bloated responses that slow down an application's performance. In GraphQL, the schema itself describes the full data model. The introspection quality means that inside any GraphQL API is the ability to query its own data model to better understand what data is available. And GraphQL's advantage of allowing clients to only call the specific data that is needed avoids hypermedia's bloat problem. As an abstraction layer that is able to draw in multiple data sources and make them available or referenced within a single schema/data model, GraphQL has huge potential for use in sectors where data comes from disparate and disconnected sources. GraphQL removes data access barriers and makes all dataregardless of the original owner or place of publicationavailable through a single schema where relevant, related data can be queried at the one time. This suggests that the fields of data science, healthcare, city services and other sectors that manage complex relational data models may see advantage in adopting GraphQL. There is no doubt there are still some challenges GraphQL must solve. More complicated operations such as writing data in bulk, managing real-time data querying via a subscription rather than polling mechanism, and managing caching and pagination are partly solved but require more testing against production use case needs. Authorization stands out as one area of work that requires significant additional tooling and a variety of options. Ultimately in 2018, GraphQL's evolution is still in its infancy, but with the rapid interest from developers and the quick iteration and availability of tooling, there are strong signs that GraphQL is becoming a legitimate option for how APIs are created and managed, offering significant performance and developer experience benefits. 2018 State of API Integration Report 39 API Security APIs are certified "cool" - they provide access to data and services otherwise locked behind corporate firewall, they enable easy development of web & mobile products, and they allow organizations to do business in new ways. But this strategic opportunity opens up vulnerabilities, and APIs are becoming the primary attack vector for unscrupulous individuals, organizations and even governments! Security then, must be a leading concern. All API stakeholders (developers, architects, operations and the business) must play a role in deploying a security model that both enables and protects. This is a list of guiding principles that API projects should follow: 1. Security features, like deciding how to deal with authentication and access control is often relegated to the last design consideration. But a robust security model must also consider your overall application architecture and find all layers where threats and vulnerabilities may exist. It's also important to think about reusability in your security architecture, making it easy for developers to leverage standardized mechanisms at each application tier. 2. Basic access control is actually pretty simple. Users and clients request to access Objects like data, applications and services. Access controls then make a decision to grant or deny that request. Today, user management is a mature space and most organizations have a central user directory. Object management must reach this same maturity, enabling better controls and improved granularity across your APIs and data model. Leverage existing standards (E.g. OAuth 2.0) to grant granular access to services. 3. Many believe security architectures are focused on keeping the bad guy out, but in fact most often the inverse is true. Access control infrastructure is designed to provide a user experience to authorized entities: employees, customers, etc. It's important to design for malice: assume that those trying to gain unauthorized access are in fact not "playing by the rules", and instead finding ways to work around the areas governed by policy. Section 01 | Section 02 | Section 03 2018 State of API Integration Report 40 Section 01 | Section 02 | Section 03 4. Users simply don't care about or understand securitythey just want easy access and peace of mind that their data is secure. Unfortunately, for a long time security measures and technologies have delegated far too much responsibility to the end user, expecting them to make educated and technical decisions. How often have you been asked "Do you trust this certificate?" in a web browser? It's not practical to assume users have the technical knowledge to understand PKIso how is it reasonable to push this responsibility to them? API security should be designed in such a way to balance user experience and security. 5. Developer experience is just as important as user experience, and knowledge around security can be dangerously lacking here too. API consumers can't be expected to know security, meaning your APIs can unwittingly create vulnerabilities by not arming developers with sufficient knowledge. For example, a developer may hit an API too many times and degrade performance. Or a developer may not know why or how to protect API and session keys. These can result in Denial of Service, and other security issues. 6. Finally, API integration patterns are evolving, and while request/ response still makes up the lion's share of implementations today, there are other models that need to be secured as well. With an increasing preference for Webhooks, Server-Sent Events and WebSockets, the client-server designation is becoming blurred. Signatures and encryption (E.g. TLS) should be considered to help protect these bi-directional integration patterns. 2018 State of API Integration Report 41 APIs are doorways that have enabled organizations to build new connections into their monolithic software and data systems. Of course, doorways work in both directions. So while an enterprise may expose its data assets and business capabilities using APIs, they are also making extensive use of external services in their own systems by relying on APIs from third parties. This multiplication of endpoints has blurred the security perimeter of the organization. The threat surface has increased and more security risks need to be managed. A manual, ad-hoc approach to securing the numerous and evolving endpoints simply does not work. Furthermore, when API security is tedious and not agile, it is considered as a roadblock to quickly delivering apps and innovations and therefore often left out of development and operational discussions. To address both issues, security teams must deliver "security as code", that is, translate security requirements into code that can run automatically at every step of the API lifecycle. This can be done by taking a DevSecOps approach and "pushing security left", considering security aspects already when doing the initial design and defining requirements setting phases. The DevSecOps mindset considers security issues as bug fixes. Security vulnerabilities are essentially bugs that can lead to unwanted outcomes in an application or a product. Like all bugs, you want to discover them as early as possible. The overall cost of fixing a bug is up to 30 times higher if discovered at production time rather than at development time. DevSecOps Approach to API Security Contributed Content from Isabelle Mauny, 42Crunch 2018 State of API Integration Report 42 At design time, organizations must take these core actions to protect the APIs: Development, security and operations teams work together throughout the API design cycle, discussing and building the API contract (preferably based on open standards like OpenAPI), deciding where the API will be deployed, and who will use it. Together, they build the API's threat model that will drive the security policies to be applied to the API. As APIs are designed, a set of pre-approved, pre-tested security policies are put in place that match the security level required. APIs are tagged depending on the risk evaluated as part the API threat modelling. The policies must address the core security aspects: Enforcing the proper TLS settings to protect the API channels Validating the API contract and the flowing data Configuring the OAuth protocol and OpenID Connect authentication flows Auditing Non-repudiation Encrypting and signing the API payload (optional) To secure APIs during runtime, the following security aspects must be automatically enforced throughout the CI/CD pipeline: Security policies are incorporated as early as possible into the continuous delivery and testing processes, and an API security gateway is deployed to enforce those policies. Code analysis tools (static and dynamic) are deployed and hooked to the CI/CD pipeline. 2018 State of API Integration Report 43 APIs are actively scanned APIs for vulnerabilities, in other words: you must hack yourself! You can start with ZAP, an OWASP open source penetration testing tool that you can plug to the CI/CD pipeline. Deployments are tested for proper TLS configuration using tools such as SSL Labs or securityheaders.io. Software and libraries are constantly kept up to date, and tools are put in place to actively monitor security vulnerabilities. Systems are constantly monitored for security alerts in order to respond promptly to attacks. In addition, it is critical to educate personnel on security risks: all concerned parties should at least know about the top 10 OWASP risks list and how to address them. Protecting and testing your APIs through a repeatable, well-defined, automated process enables the enterprise to continue to innovate at the pace required to stay competitive, without compromising on security. 2018 State of API Integration Report 44 Interactive Calculator Score the Current State of YOUR API Integration To wrap things up, we wanted to give our readers an interactive calculator to gauge how your API currently stacks up against the current state of API integration. Gauge how easy it is for API consumers to interact with your service, and how easy it is for data to move between your service and other applications. Where do you stack up against the rest of the API community? Share your score and be sure to mention #StateofAPIIntegration. CLICK HERE TO SCORE YOUR API https://hubs.ly/H0bq4kv0 2018 State of API Integration Report 45 Closing And there you have it. We hope you enjoyed seeing the data and hearing from our contributors about the trends that are set to affect APIs and application integration. Follow the conversation by using the hashtag #StateofAPIIntegration. Check out our resource center for other easy to follow information. If you have questions, or would like to learn more about Cloud Elements, contact us today! CONTACT CLOUD ELEMENTS </p>