PAST, PRESENT AND

FUTURE

OF APISJason Harmon

@jharmn

JASON

HARMON• From Austin, TX

• Head of API Design at Paypal

• Blogger at apiux.com,

pragmaticapi.com

• Organizer austinapi.com

meetup

• Youtube: API Workshop

• https://www.youtube.com/ch

annel/UCKK2ir0jqCvfB-

kzBGka_Lg

AGENDA

• What is an API?

• History of integration

• How APIs changed the

landscape

• The future of M2M +

humans

• Important people along

the way

WHAT IS AN API

• “Application Programming Interface”

• http://en.wikipedia.org/wiki/Application_programm

ing_interface

• Programming languages

• Libraries, frameworks

• Web APIs

PROGRAMMING

LANGUAGESLandmark case between Oracle and Google

http://www.programmableweb.com/news/supreme-court-reviews-oracle-v.-

google-copyright-case/elsewhere-web/2015/01/25

LIBRARIES AND

FRAMEWORKSLegal ramifications in language/framework APIs

will affect how we handle Web APIs

WHAT IS AN API

“Web APIs”

http://en.wikipedia.org/wiki/Web_API

http://en.wikipedia.org/wiki/Web_service

http://en.wikipedia.org/wiki/Representational_s

tate_transfer

THAT’s what I’m talking about

HISTORY OF APIS

It’s all about integration

These problems are not new

WESTERN UNION

TELEGRAPH1850s

http://en.wikipedia.org/wiki/First_Transcontinental_Tel

egraph

TELETYPETeletype data of 300 baud modem used in1948 Berlin Airlift

Over 200,000 flights in one year, providing up to 8,893 tons of necessities daily, such as

fuel and food

Led to formation of Transportation Data Coordinating Committee in 1968

EDIFirst standard published in 1968

EDIFirst implementation, London Heathrow 1971

EDI1978 ANSI formed Accredited Standard Committee

1983, ANSI published the first five American National Standards

for EDI

EDI1987 EDIFACT becomes international standard

United Nations/Electronic Data Interchange For Administration, Commerce

and Transport (UN/EDIFACT)

EDIIndustry specific standards proliferate

Largely complete by 1996

NOT FUN TO

LOOK ATNobody thought about

humans.

STANDARDSGovernment to government

Company to company

~30 years

THOSE WHO

CANNOT

REMEMBER THE

PAST ARE

CONDEMNED TO

REPEAT ITGeorge Santayana -1905

RESPECT HISTORY

• Standardization was slow, nearly impossible

• Global data exchange was explored

throughout the 20th century

• Developers broadly weren’t able to contribute

to these standards

INTERNETMaybe the Internet will fix this?

DATA IS NOT

ENOUGHRemote procedure calls

Distributed computing

Language Interop

XML-RPC• Dave Winer 1998

• Began collaboration with

Microsoft

• Developed within

COM/MTS team

• XML wasn’t even really a

standard yet

SOAPTook into account:

• Existing serialization formats

(ASN.1 BER, NDR, XDR, CDR,

JRMP)

• RPC protocols (GIOP/IIOP,

DCE/DCOM, RMI, ONC)

1998-1999 Version 1.0 Microsoft-

only

2000 Version 1.1 IBM modifications

2002 Version 1.2 became a W3C

recommendation on June 24, 2003

SOAPProliferation of standards

http://en.wikipedia.org/wiki/List_of_web_service_specifications

SOAPNot fun to look at either.

SOAP STANDARDSMassive effort across multiple industries

D

5 years

+5 years of non-stop expansion

ROY

FIELDINGPart of SOAP standardization

Key contributor to HTTP 1.1, URI

Co-founder of Apache HTTP

Server

Wrote a dissertation in 2000,

while defining HTTP 1.1

http://www.ics.uci.edu/~fielding/p

ubs/dissertation/rest_arch_style.

htm

REST CONSTRAINTS

“Representational State Transfer (REST)”

• Client-Server

• Stateless

• Cache

• Interface / Uniform Contract

• Layered System

• Code-On-Demand (opt)

REST IS AN

EXPRESSIO

N OF HTTPThe World Wide Web

represents the largest

implementation of a system

conforming to the REST

architectural style

NOT SO BAD

TO LOOK ATStripped down compared

to prior standards

REST STANDARDS >

NULLREST is an architectural style, not a standard

D

5 years to practical examples

+5 years of evolution

HTTP REST API

STANDARDSRestrictive standards stifle

innovation

Broad constraints are why

the web has been

successful

De facto best practices

have risen from successful

APIs

A LITTLE MORE RECENT

HISTORY

BEFORE YOU LEARN MUCH

MORE

Curators of API history

• apievangelist.com

• programmableweb.com

WEB SERVICESSOA, SOAP, XML over HTTP took off

http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-

internal-apis/

~2002

COMMERCE

SOCIAL

CLOUD/INFRASTRUCTU

RE

MOBILE

GOVERNMENTOpen Data Initiative -

http://www.whitehouse.gov/open

Long-time publisher of public data

REST OUTSIDE | SOAP

INSIDEPublic APIs in REST

Internal/Partner APIs in SOAP

https://jegatech.wordpress.com/2012/10/18/soap-vs-rest/

THE LANDSCAPE TODAY

REST WON

Now 13k

GROWTH OF APIS

Now 13k

GROWTH OF APIS

From 2014

PUBLIC APIS ARE

A STRATEGIC NECESSITY

http://www.forbes.com/site

s/mckinsey/2014/01/07/rea

dy-for-apis-three-steps-to-

unlock-the-data-economys-

most-promising-channel/

PUBLIC IS

NOT

ALWAYS

RIGHTPublic programs closing

• Netflix

• LinkedIn

Still heavily using APIs

Not strategically valuable

publicly

MAINSTREA

M• APIs are becoming

powerful

• API management

consolidation in

2013/2014

• Twilio (API-only startup)

IPO cominghttp://blogs.wsj.com/venturecapital/2015/02/20/twilio-positions-itself-for-an-ipo-after-logging-100m-in-2014-revenue/

ALL MOBILE

APPS USE

APISNot all publicly

documented

Frequently reverse

engineered

PRIVATE APIS ARE THE DARK

MATTERInternal APIs are a much, much bigger landscape

http://apiux.com/2014/02/06/dark-matter-api-

universe/

MICROSERVICESREST APIs inside and outside

http://martinfowler.com/articles/microservices.html

API ADOPTIONMachine to Machine = API

http://www.gartner.com/newsroom/id/2819918

WILL HISTORY REPEAT

ITSELF?

REST APIs offer nothing to

save us from past

complexities of integration

Microservices could be

SOA with a new brand

DEVELOPER EXPERIENCE

UX transformed the app

world

DX is an emerging field

• AKA DX, APIUX, APX

Designing developer

interfaces for humans and

machineshttp://uxmag.com/articles/effective-developer-experience

DESIGN THINKINGInterfaces humans can understand

Documentation that explains things for developers

Less reference, more guides

THE FUTURE

OF APISWhat’s next?

TRANSPAREN

CYGovernments

Companies

Personal

SHARING

CAPABILITIESCompanies are almost exclusively building on top of

APIs

Stick to core competencies

OPEN GOVERNMENTCitizens demand it

Governments need it to scale

IOT“Internet of Things”

QUANTIFIED

SELF

Sensor data about yourself

IOT ADOPTIONThe things are coming

http://www.gartner.com/newsroom/id/2819918

CONNECTED…EVERYTHI

NGAppliances, sports equipment, shoes…whatever.

CONNECTED CARSBy 2020 152 million cars will have connectivity

http://business.time.com/2014/01/07/your-car-is-about-to-get-smarter-than-

you-are/

SMART CITIESSongdo, South Korea is a cutting edge

experiment

IOT: BECAUSE BIG

DATAUnimaginable volumes of sensor data are

coming

APIS ALL

THE WAY

DOWNConnected devices will use

APIs at the edge and the

backend

PROTOCOLS

• Industrial and consumer

needs

• Pub/Sub will be critical

• Streaming sensor data

• HTTP might not be good

enough

HTTP/2

CoAP

MQTT

EDGE CONNECTIVITY

• TCP protocols often not

useful in the field

• Location-awareness

• Wifi/cell

insecure/unreliable

• Bluetooth LE

• NFC

SECURE THE THINGS

INFORMATION

WANTS TO BE

FREE … “I believe that all generally useful

information should be free. By 'free'

I am not referring to price, but

rather to the freedom to copy the

information and to adapt it to one's

own uses... When information is

generally useful, redistributing it

makes humanity wealthier no

matter who is distributing and no

matter who is receiving”Richard Stallman -1990

http://www.rogerclarke.com/II/IWtbF.html

LOFTY GOALS,

BIG RESPONSIBILITY.

A GENERATION

OR TWO LATER…

DATA BREACHES“Information wants to be free”

IF YOU WANT IT SECRET

YOU’RE GOING TO HAVE

TO WORK REALLY HARD

FOR IT.

SECURITY• The best HTTP has is

HTTPS

• Constant threats to

transmission-level security

are nerve wracking

• Government intercept and

decrypt capabilities have

left the private sector

shaken

http://dayswithoutansslexploit.com

AUTHOAuth 2 and SAML are broadly accepted

MAKING UP AUTHNot following accepted practices is perilous

“The Snappening”

http://www.reuters.com/article/2014/10/14/us-snapchat-future-security-

idUSKCN0I32UJ20141014

RELAX.There are people thinking about these things.