Wikipedia for Web APIs

Developer-driven adoption

Standard API resources

● Docs

● SDKs

● API console

New trends

● APIs for non-technical people

● 3rd-party integrations

● API flows

● IoA - Internet of APIs

iPaaSIntegration platform as a service

Consumer products

Give me more API!

Hold a minute … or month

API growth

6 days 3 days 9 days 8 days

Standard approach

Human-readable docs

Method characteristics

Arguments

Response description

Method

Method description

required?Argument type

Response type

Response description

Response description

Machine-readable docs

API version

Supported protocols

Method

Method description

Link to response description

required?

Argument type

API characteristics

Method characteristics

Response

Arguments

Would it be nice?

● All API descriptions in one place

● Documented in one format

● Anyone can add/improve API description

What does APIs.guru do?

● Filter out private and non-reliable APIs.

● Convert different formats into Swagger 2.0

● Fix mistakes, ~80% of spec have them

● Add additional data, like: logo, categories, …

● Update specs on daily basis

CPI - Cost per integration

OpenAPI + APIs.guruPublic APIs

Contribution process

Validation scriptReview

API owner

Pull requests

Contributors

API

Any-API.com

SDKs.io

CenitSaaS.com

commandcar

DataFire.io

Paw by luckymarmot.com

Tested on APIs.guru

Road map

● Minimal valuable set of APIs - Done

● Grow number of integrations - In progress

● Collaborate with API owners - In progress

● Build community - Need your help:)

ivan.goncharov.ua@gmail.com ivangon4arovhttps://git.io/APIs.guru

@APIs_guru

Join the movement

Far Far Future: Synergy

Data incompatibility

{ “First name”: “John”, “Surname”: “Smith”}

{ “Name”: “John”, “Surname”: “Smith”}

{ “Full name”: “John Smith”}

Schema incompatibility{ “properties”: { “First name”: { “type”: “string” }, “Surname”: { “type”: “string” } }}

{ “properties”: { “Name”: { “type”: “string” }, “Surname”: { “type”: “string” } }}{

“properties”: { “Full name”: { “type”: “string” } }}

Stage 1: Scalar types

{ “properties”: { “First name”: { “type”: “string” } “Surname”: { “type”: “string” } }}

{ “properties”: { “First name”: { “$ref”:

“http://apis.guru/types/name#” } “Surname”: { “$ref”:

“http://apis.guru/types/surname#” } }}

Stage 2: Complex types

{ “properties”: { “First name”: { “$ref”: “http://apis.guru/ types/name#” }, “Surname”: { “$ref”: “http://apis.guru/ types/surname#” } }}

{ “$ref”: “http://apis.guru/ types/fullname/15#”}

Stage 3: type converters

function (data) { return { “Full name”: data[“First name”] + data[“Surname”] };}

{ “First name”: “John” “Surname”: “Smith”}

{ “Full name”: “John Smith”}

Why not Hypermedia?

Cool technology, but doesn’t help iPaaS:

● Can access metadata only after first call

● Metadata only for particular entities

● Require API owner to change implementation