3. Rapid API Workshop Webinar Series
Mapping
out
your
API
Strategy
Pragma>c
REST:
API
Design
Fu
10
PaGerns
of
Successful
API
Programs
API
Metrics
–
What
to
Measure?
Today:
API
Technology
&
Opera:ons
Driving
API
Adop>on
4. Roadmap
Considera>ons
1. Can
You
See
It?
6. Some
Things
Will
Change
–
API
Visibility
–
API
Versioning
2. Don’t
have
a
Meltdown
7. Welcome
Aboard!
–
API
Traffic
Management
–
API
User
Management
3. Keys
to
Your
Kingdom
8. Field
of
Dreams
–
API
Iden>ty,
Authen>ca>on,
–
API
Community
and
and
Authoriza>on
Audience
4. Don’t
Roll
Your
Own
9. Show
Me
the
Money
–
API
Security
–
API
Mone>za>on
5. Indecent
Exposure
10.
Pump
Up
the
Volume
–
API
Data
Protec>on
–
API
Scalability
5. API
Lifecycle
Curious
Building
Launching
Growing
Expanding
• Requirements • API design • Beta customers • Scaling API • New capabilities
• Business case • Policy design • Rapid iteration • Scaling processes • New markets
• Prototyping • Development • Driving adoption • Managing growth • Tiered policies
6. API
Management
Technology
Considera>ons
vs.
Lifecycle
Performance
and
Scale
Traffic
Management
Secure
Access
Analy>cs
Developer
Enablement
Curious
Building
Launching
Growing
Expanding
7. API
Visibility
1.
Can
You
See
It?
An
API
needs
API
analy>cs
just
like
a
Website
needs
Web
analy>cs
– Understand
use
and
misuse
(oeen
accidental)
– Cri>cal
for
product
managers
(best
and
worst
features)
– Make
sure
API
supports
analy>cs
needs
(again)
Understand
business
as
well
as
transac>on
level
usage
– How
do
apps,
developers,
users
and
APIs
relate
to
each
other
– Report
on
business
content
informa>on
Use
to
monitor,
debug
and
evangelize
API
quality
– Prove
service
quality
to
users
(and
find
out
first
when
not)
– Consider
providing
analy>cs
to
developers
8. API
Visibility
1.
Can
You
See
It?
Who
is
using
the
API
and
how
much
are
they
using?
– How
many
clients,
apps,
developers
are
out
there?
– How
do
they
break
down
by
type,
region?
– How
does
usage
map
to
exis>ng
customer
or
partner
organiza>ons?
– How
do
developers
map
to
applica>ons
map
to
customers?
– What
parts
of
the
API
and
service
are
they
using?
– How
does
traffic
breakdown
between
your
own
products
and
3rd
party
products?
– What
the
aggregate
and
per
developer/app/customer
transac>on
and
data
volumes?
How
fast
and
good
is
your
service?
– What
latency
are
customers
experiencing,
by
developer,
customer,
region,
or
opera>on?
– Where
are
errors
and
user
experienced
bugs
happening
and
how
oeen?
– How
is
the
API
delivering
vs.
any
formal
SLA
have
agreed
to
or
paid
for?
– How
can
you
find
out
if
a
customer
is
having
a
problem
(before
they
call
you)?
– How
is
the
API
usage
impac>ng
the
rest
of
the
plakorm
or
web
products
that
also
use
the
same
API?
– Can
you
quickly
trap
and
debug
based
on
a
specific
message?
Based
on
what
is
in
a
cache?
9. API
Traffic
Management
2.
Don t
have
a
Meltdown
An
API
meltdown
can
cause
a
website
and
business
meltdown
– APIs
on
same
infrastructure
as
websites
need
throGling
– Many
APIs
also
power
the
website
– Proper
throGling
can
extend
capacity
beyond
peak
Understand
difference
between
traffic
management
and
business
quotas
– Don't
subs>tute
quotas
for
rate
limits
(opera>onal
traffic
flow)
– Don't
shut
off
your
best
customers
– Consider
throGling
at
the
proxy
level
to
protect
the
back-‐end.
All
requests
are
not
equal
– Consider
throGling
differently
based
on
customer,
customer
>er,
IP,
region,
...
– Can
you
provide
customers
with
data
so
they
can
meter
themselves?
– Some
messages
are
transac>onal
and
may
need
queuing
10. API
Traffic
Management
2.
Don t
have
a
Meltdown
What
kinds
of
rate
limi>ng
do
you
need?
– Do
you
need
to
rate
limit
by
developer,
app,
or
customer
organiza>on?
– Can
you
rate
limit
a
par>cular
client
(key
and
IP
address)?
– Are
all
messages
the
same
or
do
you
need
to
adjust
based
on
message
size,
or
records
per
message,
or
bandwidth?
– How
do
you
throGle
differently
for
your
own
web
or
internal
apps
vs.
API
traffic?
– Do
you
need
to
buffer
or
queue
requests?
Does
your
business
need
quotas
on
API
usage?
– Do
you
need
to
keep
track
of
daily
or
monthly
usage
to
measure
business
consump>on?
– Do
you
need
to
define
different
consump>on
levels
for
different
service
>ers?
– If
someone
goes
over
the
quota,
what
is
the
best
business
recourse?
Call
them
up
and
upsell
them?
Or
shut
them
off?
– If
you
are
paying
for
the
data
are
you
measuring
this
for
billing
and
pricing?
How
do
you
monitor
and
respond
to
traffic
management?
– How
will
you
know
when
someone
goes
over
a
rate
limit
or
quota?
– Are
quota
or
rate
limit
overages
a
trend
or
a
'one
>me
thing'?
– Can
you
define
flexible
ac>ons?
(I.e.
drop
requests,
do
nothing,
send
an
alert?)
– Can
you
provide
customers
with
data
so
they
can
help
by
metering
themselves?
11. API
Iden>ty,
Authen>ca>on,
and
Authoriza>on
3.
Keys
to
Your
kingdom
Understand
need
for
Iden>ty
vs.
Authen>ca>on
– Example:
Google
Maps
API
(only
needs
ID)
– TwiGer
API
(needs
auth)
Security
Lessons
learned
– Consider
API
keys
for
iden>ty
without
authoriza>on
– Consider
basic
auth
to
keep
it
simple
– Consider
Oauth
for
server-‐server
APIs
based
on
websites
– Use
SSL
for
everything
sensi>ve
– Avoid
session
based
authen>ca>on
– Avoid
rolling
your
own!
Know
your
audience
– Enterprise?
Might
need
SOAP,
SAML,
2-‐way
SSL,
X.509
– Web
developer?
Keep
It
simple
12. API
Iden>ty,
Authen>ca>on,
and
Authoriza>on
3.
Keys
to
Your
kingdom
Iden>ty
–
who
is
making
an
API
request?
– Example:
Google
Maps
API
vs.
TwiGer
API
– Which
APIs
are
public
opera>ons?
– Which
APIs
are
private
opera>ons?
– Which
APIs
are
idempotent
opera>ons?
– Which
APIs
are
potent
opera>ons?
Authen>ca>on
–
are
they
really
are
who
they
say
they
are?
– Disambigua>on
but
not
security:
API
Key
only
– Username,
password,
and
creden>al
mapping
– The
basics:
HTTP
Basic
+
SSL
– Session-‐based
authen>ca>on:
the
enemy
of
RESTful
APIs
– Condi>onal
Authority:
The
role
of
OAuth
– Enterprise
authen>ca>on:
SAML,
X.509,
and
Two-‐Way
SSL
– Not
recommended:
Custom
encryp>on
Authoriza>on
–
are
they
allowed
to
do
what
they
are
trying
to
do?
– Which
dimensions
of
iden>ty
are
important
for
the
API?
• User,
Applica>on,
Developer
– Do
the
rights
need
to
be
dynamic?
– Can
user
or
applica>ons
have
their
rights
changed
on
the
fly?
– What
capabili>es
does
this
offer
or
restrict
in
the
business?
13. API
Security
4.
Don t
Roll
Your
Own
How
valuable
is
the
data
exposed
by
your
API?
– If
it s
not
that
valuable,
or
if
you
plan
to
make
it
as
open
as
possible,
is
an
API
enough
to
uniquely
iden>fy
users?
– If
it
is
valuable,
can
you
reuse
username
and
password
scheme
for
each
user?
– Are
you
using
SSL?
Many
authen>ca>on
schemes
are
vulnerable
without
it
What
other
schemes
and
websites
will
your
API
and
users
want
to
integrate
with?
– If
your
API
will
be
called
programma>cally
by
other
APIs,
or
if
your
API
is
linked
to
another
web
site
that
requires
authen>ca>on,
have
you
considered
OAuth?
– If
you
have
username/password
authen>ca>on,
have
you
considered
OpenID?
– Can
you
make
authoriza>on
decisions
in
a
central
place?
What
other
expecta>ons
might
your
customers
have?
– If
your
customers
are
enterprise
customers,
would
they
feel
beGer
about
SAML
or
X.509
cer>ficates?
– Can
you
change
or
support
more
than
one
your
authen>ca>on
approach
for
diverse
enterprise
customers?
– Do
they
have
an
exis>ng
internal
security
infrastructure
that
they
need
your
API
to
interact
with?
14. API
Data
Protec>on
5.
Indecent
Exposure
Encryp>on
–
protec>ng
your
API
data
from
eavesdropping
– Use
SSL
encryp>on
if
API
includes
sensi>ve
data
– XML
encryp>on:
securing
the
payload
for
delivery
behind
the
firewall
to
a
trusted
client
Threat
detec>on
–
ensuring
client
API
requests
won t
cause
back-‐end
problems
– Always
defend
against
SQL
injec>on:
takes
advantage
of
internal
systems
that
construct
database
queries
using
string
concatena>on
– XML
aGacks:
large
or
deeply
nested
XML
documents
which
cause
the
backend
server
to
use
excessive
resources;
If
your
API
accepts
XML
input
via
HTTP
POST
Data
masking
–
prevent
sensi>ve
data
exposure
or
mask
private/premium
data
– Removing
or
obscuring
specific
fields
based
on
user
rights
– Eliminate
specific
data
from
all
responses
based
on
origina>ng
IP
address
– Dis>nguishing
between
core
web
applica>on
access
and
programma>c
access
15. API
Data
Protec>on
5.
Indecent
Exposure
What
types
of
sensi>ve
data
is
being
passed
on
the
wire?
– Personally
iden>fiable
informa>on
– Credit
card
or
financial
informa>on
What
regula>ons
or
policies
apply
to
this
data?
– HIPAA
– PCI
– Internal
audit
Encryp>on
–
protec>ng
your
API
data
from
eavesdropping
– XML
encryp>on:
securing
the
payload
for
delivery
behind
the
firewall
to
a
trusted
client
– SSL
encryp>on:
securing
the
transport
itself
for
all
data
but
leaving
it
open
once
delivered
Threat
detec>on
–
ensuring
client
API
requests
won t
cause
back-‐end
problems
– SQL
injec>on:
takes
advantage
of
internal
systems
that
construct
database
queries
using
string
concatena>on
– XML
aGacks:
large
or
deeply
nested
XML
documents
which
cause
the
backend
server
to
use
excessive
resources
– Denial
of
Service:
repeated
requests
from
a
single
client
or
set
of
clients
to
a
given
API
– Header
bombs:
malformed
headers
that
lead
to
excessive
resource
usage
and
crashes
Data
masking
–
preven>ng
inadvertent
data
exposure
in
API
responses
– Replay
aGacks:
re-‐sending
intercepted
valid
data,
possibly
including
altera>on
of
some
fields
– Removing
or
obscuring
specific
fields
based
on
user
rights
– Elimina>ng
specific
types
of
data
from
all
responses
based
on
origina>ng
IP
address
– Dis>nguishing
between
core
web
applica>on
access
and
programma>c
access
16. API
Versioning
and
Media>on
6.
Things
Will
Change
Prolifera:on
of
API
varia:ons
and
versions
can
consume
many
development
and
opera:ons
cycles
– Lesson
learned
–
Truecredit.com
–
calculated
thousands
of
versions
to
support
major
partners,
opted
for
a
media>on
layer
Media>on
considera>ons
– Protocols
-‐
maintain
one
API
endpoint
and
mediate
protocols
for
different
audiences
– Versioning
-‐
avoid
maintaining
two
version
–
mediate
to
hold
a
previous
version
fixed
– Creden>als
–
mediate
across
different
security
schemes
– Mone>za>on
-‐
enrich
fields
to
create
mone>zed
version
of
API
– Standardize
-‐
standardize
elements
of
mul>ple
APIs
to
create
unified
experience
17. API
Versioning
and
Media>on
6.
Things
Will
Change
Will
you
need
to
mediate
protocols?
– Do
you
an>cipate
needing
to
offer
more
than
one
protocol
or
a
different
protocol
to
what
you
have
now?
(SOAP
for
enterprise
customers?
REST
or
JSON
for
developer
adop>on?
)
– Do
you
an>cipate
needing
to
map
across
different
security
or
creden>al
schemes?
(ex:
from
simple
HTTP
auth
to
WS-‐Security)
– Do
you
currently
write
a
lot
of
code
to
transform
between
different
styles
of
a
par>cular
protocol
(SOAP
1.1
vs.
1.2,
etc.)
– How
important
will
it
be
to
reduce
the
number
of
APIs
versions
for
development
and
maintenance?
Version
management
– How
oeen
will
you
need
to
release
upgrades
to
the
API?
– What
is
your
process
for
asking
customers
to
upgrade
and
how
long
will
it
take
to
sunset
a
version?
– If
you
offer
more
than
one
API,
do
you
have
a
need
to
standardize
elements
of
the
API
(header
or
payload)?
– Do
different
teams
need
to
do
this
or
does
it
make
sense
to
put
this
capability
at
one
point?
Message
enrichment,
clipping
– Will
you
ever
need
to
enrich
an
API
for
a
par>cular
customer
or
class
of
service
with
more
data
or
func>onality?
– Will
you
need
to
remove
or
clip
certain
fields
for
certain
customers
or
classes
of
service?
– How
fast
will
you
need
to
turnaround
these
requests
for
the
business
vs.
your
dev
or
product
cycle?
18. API
Developer
Onboarding
7.
Welcome
Aboard
Make
it
easy
– Minimize
>me
to
get
started
– Amount
of
informa>on
for
sign-‐up
Set
infrastructure
for
adding,
maintaining
and
dele>ng
accounts
– Key
provisioning
(API
and
Oauth)
– Define
common
user
profiles
with
preset
access
– Prac>ce
on-‐boarding
processes
before
launch
Do
you
need
to
start
from
scratch?
– Use
exis>ng
SFA
systems?
(such
as
Salesforce.com)
– Integra>on
with
sales,
support,
and
ERP
systems?
19. API
Developer
Onboarding
7.
Welcome
Aboard
For
on-‐boarding
developers
– Do
you
already
have
a
way
to
manage
user
accounts
that
you
plan
to
re-‐use
for
your
API?
Or
have
you
considered
it?
– If
you
have,
do
you
also
wish
to
offer
OAuth
keys?
– If
you
have
no
user
management
at
all,
what
does
a
user
need
to
do
in
order
to
sign
up
to
use
your
API?
– Can
they
sign
up
quickly
and
easily
using
a
web
browser?
– Can
you
simplify
things
by
defining
>ers
of
users?
– What
kind
of
informa>on
do
they
need
to
have
access
to?
For
maintaining
and
managing
accounts
– Can
you
re-‐set
passwords?
– Can
you
delegate
this
ability
in
the
case
of
partners
who
generate
their
own
affiliates?
– What
user
interface
do
you
want
to
create
for
user
management?
– Can
users
do
it
using
a
web
site
or
is
there
some
other
way?
– Can
you
monitor
their
usage?
Can
they
monitor
it
themselves
– Can
you
revoke
user
accounts?
– Do
you
need
to
implement
an
approval
or
screening
process?
– Do
you
need
repor>ng
and
analy>cs
around
users
–
ac>ve
developers,
engagement
and
reten>on
rates?
Integra>ng
your
API
users
into
the
rest
of
your
business
– Does
your
developer
ac>vity
need
to
get
mapped
into
your
sales,
support,
and
ERP
systems?
– Does
your
API
key
structure
enable
you
to
map
developers
to
applica>ons,
your
customers,
and
their
end
users?
– Does
user
data
need
to
be
integrated
with
exis>ng
profiles
or
user
data
systems?
Can
you
use
exis>ng
SSO
(single
sign-‐on)
systems?
– Can
you
create
the
right
usage
incen>ves
by
providing
developer
access
to
their
own
usage
data?
20. API
Community
and
Audience
8.
Field
of
Dreams
Think
about
Audience,
Tools,
Community
– Not
just
about
the
Tools
or
Portal
– like
party
where
you
you
need
to
take
hats
and
coats
"
Audience
( get
the
word
out )
– Get
your
content
where
the
developers
are
– Plug
into
other
developer
communi>es.
– Best
content
–
code
samples
and
examples.
Release
internal
hack
day
examples!
Tools
("catering,
tables
and
chairs")
– Have
clear
owners
of
developer
community
processes
– Dress
rehearse
processes
with
the
tools
– Need
tools
for
on-‐boarding,
support,
social
media
(customer
outreach)
Community
("make
sure
people
mingle")
– Build
create
customer
advocates
that
will
go
to
bat
for
you
(Hoovers
example)
– Best
way
=
point
out
cool
apps
they
are
building
– Internal
developers
can
be
best
advocates
(Yahoo
Hack
Day
example)
– Target
both
online
and
offline
events
21. API
Community
and
Audience
8.
Field
of
Dreams
Community
enablers
– Do
you
have
formal
documenta>on?
– Can
you
put
it
on
a
wiki
so
that
developers
can
edit,
add,
and
comment?
– Do
you
have
code
samples
on
how
to
use
the
API?
– Do
you
have
a
place
for
developers
to
put
their
own
code
samples
and
showcase
their
own
work
and
sample
apps?
(widgets,
mobile
apps,
etc.)
– Are
code
libraries
needed
for
important
plakorms?
– Should
these
be
open
source?
– Do
you
have
a
blog
for
best
prac>ces
and
a
way
to
get
in
touch
with
developers
on
important
changes
(such
as
API
version
updates?)
Audience
and
distribu>on
– Can
you
get
awareness
and
distribu>on
through
exis>ng
developer
communi>es,
such
as
any
vendor
(MS,
Google,
IBM),
Plakorm
(Ruby,
iPhone),
Independent,
Directories
(programmableweb)
– What
Web
marke>ng
or
SEO/SEM
(Search
Engine
Op>miza>on
or
Search
Engine
Marke>ng/
Adwords)
can
you
do
to
make
sure
developers
find
you
when
searching
for
API
+
your
type
of
content
or
business .
– Community
support
and
tools
Community
management
– Should
you
have
a
dedicated
full-‐>me
employee
to
drive
community
and
evangelize
your
product
and
best
developers?
– Are
there
any
offline
events
or
meetups
you
should
be
at?
– How
can
you
recognize
and
promote
your
hardcore
community
members?
Do
you
have
an
evangelist
that
knows
these
folks
personally?
– Are
you
ac>vely
researching
their
opportuni>es
for
revenue
through
recombining
your
services?
– Is
there
a
small
group
you
can
pay
to
build
the
first
applica>ons
and
prime
the
pump
for
mass
adop>on?
22. API
Mone>za>on
9.
Show
Me
the
Money
General
business
and
partner
model
ques>ons
– How
is
your
business
and
revenue
model
supported
by
your
API?
– Does
the
API
drive
a
mone>zed
transac>on?
– Will
you
ever
charge
for
pay
by
the
API
drink
for
some
parts
of
your
API?
– How
are
your
costs
reflected
in
your
API?
Do
you
pay
for
any
of
the
data
you
are
serving
up?
If
so,
how
do
you
keep
track
of
this
for
the
business
and
partner?
– Will
large
partners
or
deals
surface
where
your
team
will
need
to
change
the
API
content,
SLA,
protocol
or
content?
– Is
there
a
partner
that
might
want
to
pay
enough
and
who
is
large
enough
to
drive
your
team
to
move
a
way
from
one
size
fits
all?
– Will
you
need
to
create
service
>ers ?
Enforcing
unique
business
and
opera>onal
terms
– How
will
you
meter
service
like
a
u>lity,
so
that
you
can
bill
partners
and
report
data
costs?
– What
regulatory
compliance
will
you
need
to
support?
Do
you
need
SOX-‐compliant
audit
trails
by
partner?
HIPPA?
PCI?
– How
would
you
create
and
enforce
a
partner
specific
SLA,
rate
limit,
or
offer
priority
access
to
a
priority
partner?
– If
the
partner
wants
any
change
in
the
API
protocol
or
content
–
do
you
need
to
support
a
different
API
code-‐base?
– Is
there
a
way
to
create
a
transforma>on
layer
to
handle
and
scale
this?
– Do
you
need
to
buffer
up
or
queue
incoming
requests?
23. API
Scalability
10.
Pump
Up
the
Volume
Are
you
prepared
for
10,
100,
or
10,000
:mes
the
current
volume?
– May
require
fundamental
changes
to
your
technology
and
architecture.
– Do
you
need
to
deliver
globally?
Caching
– Reduces
latency,
improves
throughput
by
protec>ng
back-‐end
services
– Consider
caching
frequent
API
responses
Rate-‐limi:ng
and
threat-‐detec:on
– Keep
unecessary
traffic
away
from
the
back-‐end
Offloading
– Resource-‐intensive
repe>>ve
tasks
like
SSL,
HTTP
connec>on
management,
authen>ca>on,
valida>on,
and
compression
24. API
Scalability
10.
Pump
Up
the
Volume
Key
scalability
ques>ons
to
ask
for
your
roadmap
– What
kind
of
volume
are
you
expec>ng?
– Are
you
prepared
if
you
get
10,
100,
or
10,000
>mes
that
amount
of
volume
with
liGle
warning?
– Are
your
back
end
servers
capable
of
handling
tens
of
thousands
of
concurrent
connec>ons?
– Are
you
monitoring
response
>mes
and
tracking
them
to
gauge
customer
sa>sfac>on?
Caching
– Are
your
back
end
services
cacheable?
– Do
you
have
a
cache
that
you
can
use
to
reduce
response
>mes?
• Between
the
applica>on
server
and
the
database?
• Within
the
applica>on
server?
• Between
the
applica>on
server
and
the
range
of
API
clients?
Rate-‐limi>ng
– Do
you
have
a
way
to
shut
a
user
off
if
they
consume
too
much
volume?
– Do
you
have
a
way
to
control
API
traffic
in
case
you
are
unable
to
handle
the
volume
at
some
point?
– Is
this
consistent
with
your
threat
detec>on
infrastructure?
Offloading
– Are
you
protec>ng
the
applica>on
servers
bby
offloading
resource-‐intensive
repe>>ve
tasks
like
SSL,
HTTP
connec>on
management,
authen>ca>on,
valida>on,
and
compression?
25. What
We
Covered
1. Can
You
See
It?
6. Some
Things
Will
Change
–
API
Visibility
–
API
Versioning
2. Don’t
have
a
Meltdown
7. Welcome
Aboard!
–
API
Traffic
Management
–
API
User
Management
3. Keys
to
Your
Kingdom
8. Field
of
Dreams
–
API
Iden>ty,
Authen>ca>on,
–
API
Community
and
and
Authoriza>on
Audience
4. Don’t
Roll
Your
Own
9. Show
Me
the
Money
–
API
Security
–
API
Mone>za>on
5. Indecent
Exposure
10.
Pump
Up
the
Volume
–
API
Data
Protec>on
–
API
Scalability
27. Rapid API Workshop Webinar Series
Mapping
out
your
API
Strategy
Pragma>c
REST:
API
Design
Fu
10
PaGerns
in
Successful
API
Programs
Today:
API
Metrics
–
What
to
Measure?
API
Technology
&
Opera>ons
Driving
API
Adop:on
28. THANK
YOU
Ques%ons
and
ideas
to:
@gbrail
@landlessness
@apigee