The API (R)Evolution
1) A new era for APIs
2) SOAP -> REST -> MICROSERVICES
3) Explosion of clients, including WebSockets and HTML5 applications
4) New challenges, new platforms, new stacks
5) What the future will look like, and how our clients will have to adapt
2. The API R(E)volution
● Open-Source
● 4M+ Downloads since 2015
● Built on top of NGINX
● Extensible with Plugins (60+ available)
● Sub-millisecond latency on most use-cases
● Cloud-Native & Platform Agnostic
● Fast and Scalable. Up and running in minutes
● CE and EE editions
Millions of Community (CE) downloads
across multiple platforms.
■ 12,000+ Stars in GitHub
■ 70+ Contributors
■ 107 Meetups
■ 10K Community Members
A few words about Kong
3. The API R(E)volution
I’m Marco Palladino
CTO @ Kong
Located in San Francisco and…
- Singapore
- New York
- London
- Canada
- México
- Brazil
- ...and Finland.
* Used to be Mashape
4. The API R(E)volution
APIs are continuously evolving
SOAP
XML
REST
Primarily JSON
REST+RPC
JSON- gPRC - etc
5. The API R(E)volution
Because architectures are evolving
All product names, logos, and brands are property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does
not imply endorsement.
6. The API R(E)volution
Explosion of clients Inside and Outside the organization
FaaS
Other Microservices
Partners
Web Applications
APIs
7. The API R(E)volution
SOAP
● Easier than COM, CORBA, etc
● But still hard to consume
● Heavyweight
● Hard to read
(1999 - 2007)
8. The API R(E)volution
JSON REST
● Easy to consume
● More compact
● Follows HTTP best practices
(2007—Today)
19. The API R(E)volution
Service-to-Service
Microservices and clients directly consume and
invoke other microservices
Ideal for external clients and/or response
aggregation use-cases, or when an immediate
response is required
Done via HTTP, TCP/UDP, gRPC, etc
Example: Making a request to retrieve an immediate
response of some sort. External access use-cases
(ie, retrieve list of users)
Asynchronous
Microservices and clients push events into an event
collector that’s being consumed by other
microservices
Ideal for microservice-to-microservice
communication for changing state without requiring
an immediate response
Done via Kafka, RabbitMQ, AWS SQS, etc
Example: Making a request that doesn’t require an
immediate response (ie “orderCreated” event that
triggers an invoice creation by another microservice)
Two ways for Microservice communication: