In this presentation we will see the principles of API description languages and those of API Discovery. And understand why public catalogs of API definitions is core of future IoA. Whole talk is based on APIs.guru project as example of such catalog.

1. Wikipedia for Web APIs

2. Developer-driven adoption

3. Standard API resources
● Docs
● SDKs
● API console

4. New trends
● APIs for non-technical people
● 3rd-party integrations
● API flows
● IoA - Internet of APIs

5. iPaaS
Integration platform as a service

6. Consumer products

7. Give me more API!

8. Hold a minute … or month

9. API growth

10. 6 days 3 days 9 days 8 days
Standard approach

11. Human-readable docs
Method
characteristics
Arguments
Response
description
Method
Method description
required?
Argument type
Response type
Response description
Response description

12. Machine-readable docs
API version
Supported protocols
Method
Method
description
Link to response
description
required?
Argument type
API
characteristics
Method
characteristics
Response
Arguments

13. Would it be nice?
● All API descriptions in one place
● Documented in one format
● Anyone can add/improve API description

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

15. CPI - Cost per integration
OpenAPI + APIs.guru
Public APIs

16. Contribution process
Validation script
Review
API
owner
Pull requests
Contributors
API

17. Any-API.com

18. SDKs.io

19. CenitSaaS.com

20. commandcar

21. DataFire.io

22. Paw by luckymarmot.com

23. Tested on APIs.guru

24. 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:)

25. ivan.goncharov.ua@gmail.com ivangon4arovhttps://git.io/APIs.guru
@APIs_guru
Join the movement

26. Far Far Future: Synergy

27. Data incompatibility
{
“First name”: “John”,
“Surname”: “Smith”
}
{
“Name”: “John”,
“Surname”: “Smith”
}
{
“Full name”: “John Smith”
}

28. Schema incompatibility
{
“properties”: {
“First name”: {
“type”: “string”
},
“Surname”: {
“type”: “string”
}
}
}
{
“properties”: {
“Name”: {
“type”: “string”
},
“Surname”: {
“type”: “string”
}
}
}
{
“properties”: {
“Full name”: {
“type”: “string”
}
}
}

29. 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#”
}
}
}

30. 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#”
}

31. Stage 3: type converters
function (data) {
return {
“Full name”: data[“First name”] + data[“Surname”]
};
}
{
“First name”: “John”
“Surname”: “Smith”
}
{
“Full name”: “John Smith”
}

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