Developing a Best-in-Class API Integration

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 .

the report is a manifest of data collected over the past year, primarily from the 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 complementary research had also been gathered from the smartbear state of api report 2016 , the 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.

you can download the state of api integration report here .

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 manifested?

• 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.

i'm 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. it's quite easy to transform a soap service to create a loosely rest-ful one, 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 and 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 and is the number one pain point i encounter. i have signed up for thousands 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. lines 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 newfound 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 is how apis can, in equal parts, enable the business to do things, and also keep an eye on governance, data security, and regulatory compliance.
• doing apis wholeheartedly (not in a halfway view) speaks to the proper governance and healthy operation because you’re thinking deeply about what are the apis, how to discover them, how we auth and handle identification, etc., having this world mapped out and having sensible conversations between not just developers and it but also business users, partners, and consumers and users. in theory, outside of the it silos, 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.