Developing a Best-in-Class API Integration

By Hannah Shain in API Industry Trends Posted Mar 31, 2017

From January 2010 to January 2016, we saw a prolific increase in web APIs. As a result, API integration has become an integral part of business development, strategy and scalability. To illustrate this growth, along with the important trends and key components of success, today we announce the first annual State of API Integration Report for 2017.

State-api-book.jpgThe report is a manifest of data collected over the past year, primarily from Cloud Elements arsenal of API connectors including 165 public applications, 28,000 integration instances, and over 1.6 billion API calls. Not only did the Cloud Elements platform of APIs provide a rich dataset for the research, but also complementary research had been gathered from SmartBear State of API Report 2016, Datanyze Market Share Reports of 2016, and the ProgrammableWeb API Directory Research 2017.

I encourage you to download the State of API Integration Report to consume our research, understand our benchmarks, and dig into the results we have gathered over the past year. The data culminates to an API Integration Scorecard, where you can rank your own API against the criteria unveiled in the report.


In the exclusive, pre-launch webinar, Mark Geene was joined by Ross Garrett and Kin Lane to unveil the results of this comprehensive report and engage in dialog on some of the most pressing topics. Did you miss the broadcast? Don’t worry, we’ve got you covered. Catch the audience Q&A below and watch the replay.

“The large majority of web applications are leveraging the power of APIs, even if you don’t know it. The democratization of APIs has given you, the end user, more control. That said, developers often complain about the challenges associated with integration. In fact, research shows that roughly 39% of enterprises want easier integration between APIs and the tools they already use.”

 Live Broadcast Audience Q&A: 

  • In what ways have you seen the growth in the API Economy manifest?
    • The original driver was more of a hobby when it was just about websites and affiliate programs, and then mobile kicked things into gear in 2010. The hype grew as it spread to more device-based, cycling around Internet of Things.
    • Most of the growth in 2016/2017 is with regular business users coming on board, and understanding the importance of using APIs to do business on the web. Adoption by the average business users is what is driving adoption.
  • Curious about private or enterprise APIs that conform to the good REST-type syntax advantages.
    • Taking REST as a silver-bullet and trying to conform enterprise services to truly, full REST might not always be the best solution.There are good reasons to evolve SOAP Services and more private, internal APIs. Quite easy to transform a SOAP service to create a loosely REST-ful, supporting a hypermedia interface which may offer a quick win, making your enterprise more integration-friendly.
  • Can you comment on cases or industries where OAuth2 should not be the default?
      • Depends on how you implement a package. Google, for example, moves between OAuth1 to OAuth2 quite frequently. It comes down to how the actual mechanism is used to discover the OAuth endpoints, how you get your tokens to execute. Developers require a playgrounds / testers/ tools to better understand what you’re offering. Advice to you is to do your due diligence on all other implementations to understand the pain points and how they may be doing things wrong.
      • In addition, API keys are just about identification. Identifying who is accessing things so you can rate limit and control things. If there is not PII (Personally Identifiable Identification) involved, if there’s not data owned by a specific user, then you really don’t need OAuth, it’s overkill. There are ways to simplify OAuth in those cases. You don’t really need to secure it in a way you would need to with PIIs, just provide the keys if you need to log data, for example.
  • What about challenges that exist even before development - like friction during the signup process?
      • Friction in the signup process goes hand-in-hand with the OAuth process, is the number one pain point I encounter. I have signed up for 1000s of APIs, and I actually get paid by providers to help them eliminate friction on the signup process. Providers need to use other people’s APIs, and go through the other APIs. Don’t go through just the few that you are familiar with, but go outside your box. See how well some do it, how badly others do it. Learn through that journey, what practices you can implement. Use the OAuth or Openid like Github, Facebook, Twitter, etc to eliminate additional barriers to creating accounts.
  • What about repurposing private old-fashioned APIs to externally published and REST consumable?
      • If you asked a lot of organizations, they might tell you that they don’t have an API. And that’s just simply not true. Line of Businesses (LOBs) likely just don’t know about them because they’re in the bowels of the organization. There is a lot of opportunity to be had from simply transforming the cogs that make your business work today into services that can be exposed to partners or new channels to market.
      • We’ve seen this to be reasonably successful in a lot of industries. For example, Expedia uses an affiliate program to drive a lot of their business. AT&T and other telecom companies have turned their core business functions into APIs that developers can interact with. There’s no reason that the backend, private SOAP interfaces cannot be turned into externally facing RESTful APIs. They need to be secured. They will need to be transformed into something RESTful. We’ll need to look at the developer experience you’re offering. And they’ll need to be integration-friendly.
  • How does this "API thing" and the legacy enterprise IT compliance world, ITIL etc. work together and coexist together?
    • Where we’ve gotten within IT is that a lot of parts across the organization have taken their new found ability to connect apps together, and run away. And now IT doesn’t know what’s really happening anymore. Ultimately this has caused us to lose central governance. What we need to consider how APIs can, in equal parts, enable the business to do things, and also keeping an eye on governance, data security and regulatory compliance.
    • Doing APIs whole heartedly (not in a halfway view) speaks to the proper governance, and healthy operation. Because you’re thinking deeply about what are the APIs, how do we discover them, how do we auth and handle identification, etc. Having this world mapped out and having sensible conversations between not just developers, IT, but also business users, partners, and consumers and users. In theory outside of the IT silos, then this provides a much richer platform for sensible governance. An organic sense of governance, not the heavy handed governance that we saw with SOAP. We want a more democratic, organic level of governance.

error-codes-youre-better-than-this-1.gifDownload the Report