A
brief
history...
• Qype’s
API
is
deployed
as
a
RoR
2.3
app
• Online
since
end
of
2008
• Primary
purpose
was
serving
the
iOS
app
• Strictly
REST-‐ful,
small
feature
set
Today
• Load
~60M
req/month
• ~2000
registered
consumers
• 99%
of
traffic
caused
by
0.01%
of
consumers
• Consumers
vastly
differ
in
requirements
• REST
paradigm
broken
up
in
many
places
Today
(cont.)
• Over
the
years,
complexity
grew
with
the
requirements
– More
feature
rich
mobile
apps
– MORE
mobile
apps
– More
diverse
API
consumers
• The
result?
Service
APIs
vs.
Websites
• Mistakes
in
API
design
are
not
forgiven!
– Client
lock-‐in
• Clients
can
differ
vastly
– Mobile
app
vs.
Web
mash-‐up
• Authen3ca3on
and
access
control
– An
API
is
meant
to
access
your
core
data
by
design
• Performance
maDers
(even
more)
Versioning
• Granularity
– service
vs
endpoint
versioning
• Architecture/deployment
– One
app
per
version?
• E.g.
qype-‐api-‐v2
– One
engine
per
version?
• E.g.
app/engines/v2
– One
class
per
version?
• E.g.
app/controllers/resource_controller_v2.rb
Versioning
(cont.)
• Tes3ng?
– i.e.
to
which
version
does
a
test
apply?
• Code
sharing
vs.
code
duplica3on?
– i.e.
not
all
routes
may
change
with
an
increment
• Also
affects
caching
etc.
• Gems:
– hDps://github.com/bploetz/versionist
– hDps://github.com/filtersquad/rocket_pants
But:
simple
can
be
bad!
• Our
apps
are
not
simple
• Hence,
a
simple
API
is
not
always
suitable
• REST
paradigm
can
be
sokened
on
an
AAL
– Batch
requests
– {
“requests”:
[
{
“method”:
“get”,
“uri”:
“hDp://...”
}
...
]
}
Acceptance
tes3ng
• Crea3ng
an
acceptance
test
suite
for
a
service
API
is
not
simple
• Recommended
for
deep
end-‐2-‐end
tests
• Test
set-‐up
/
tear-‐down
• RSpec
+
consumer
subjects
Documenta3on
• Bad:
put
away
in
a
wiki
• Good:
close
to
the
code
• BeDer:
is
part
of
the
code
– Leverage
REST
representa3ons
– Self-‐documen3ng
API
code