WSO2CON 2024 - Building a Digital Government in Uganda
APIs : Mapping the way
1. APIs
Mapping
the
Way
Paul
Fremantle
CTO,
WSO2
@pzfreo
#wso2
paul@wso2.com
2.
3. Mapping
the
Way
• Looking
back
–
where
have
we
come
from
• Current
state
of
the
world
• Taking
a
look
to
the
future
4.
5. APIs
• An
API
is
a
business
capability
delivered
over
the
Internet
to
internal
or
external
consumers
–
–
–
–
Network
accessible
funcLon
Available
using
standard
web
protocols
With
well-‐defined
interfaces
Designed
for
access
by
third-‐parLes
• A
Managed
API
is:
–
–
–
–
AcLvely
adverLsed
and
subscribe-‐able
Available
with
SLAs
Secured,
authenLcated,
authorized
and
protected
Monitored
and
moneLzed
with
analyLcs
6. Web
API
History
• The
earliest
APIs
were
various
XML
and
SOAP
services
– Also
people
manipulaLng
web
applicaLons
and
parsing
HTML
10. Key
differenLators
in
the
evoluLon
• Self-‐signup
/
Portal
/
API
Store
• A
clear
moneLzaLon
model
– And
a
clear
value
model
• Ecosystem
thinking
– Hackathons
– Forums*
– Social
Media
integraLon
• Monitoring
• Simple
keys
to
OAuth
to
OAuth2
*
yes,
I
know
the
proper
LaLn
is
fora.
I’m
not
an
ancient
Roman
though
11. REST
or
rest?
• REST
–
RepresentaLonal
State
Transfer
– From
Roy
Fielding’s
thesis
(hbp://freo.me/O9t4nj)
• A
clear
shie
from
SOAP/HTTP
to
more
resful
JSON/HTTP
• REST
is
a
good
thing
–
but
actually
quite
rare
amongst
many
APIs
12. PrioriLzing
which
bits
of
REST
•
•
•
•
Proper
use
of
verbs
Caching
and
cache-‐ability
Good
error
codes
Do
not
use
poorly
defined
aspects
of
the
HTTP
spec
– E.g.
including
an
EnLty
Body
with
a
DELETE
• Re-‐usable
/
bookmark-‐able
links
and
URIs
• HATEAOS
14. Versioning
• There
are
some
who
say
that
APIs
should
NEVER
have
a
version
number
in
the
URI
• I
disagree:
– Versioning
properly
allows
for
evoluLon
and
agility
– Clear
deprecaLon
and
well-‐defined
support
for
old
versions
16. Minimum
Viable
API
• Minimum
Viable
Product
has
just
enough
features
that
the
product
can
be
deployed
and
used
by
some
customers,
and
no
more.
– Typically
this
is
a
small
subset
of
the
future
customer
base
• “Minimum
Viable
API”
is
just
enough
API
that
it
can
be
used
by
some
partners
• Highly
recommended
especially
in
evolving
an
API
strategy
17.
18. API
First
• Start
with
the
API
– Before
the
website
/
mobile
app
/
internal
app
/
…
• Why?
– Ensures
a
good
API
– External
Developers
are
not
second
class
ciLzens
– Inherently
“mobile-‐first-‐friendly”
– Decoupled
development
– Evolve-‐ability
– APIs
everywhere
19. API
First
has
requirements
•
•
•
•
Excellent
access
control
Versioning
and
agile
Throbling
Metering
and
moneLzaLon
20. OAuth2
• OAuth2
has
widely
taken
over
from
simple
API
keys
– E.g.
Google,
Github,
Twiber,
etc
• Standard
model
from
the
IETF
• Almost
the
same
as
a
simple
key
– Well-‐defined
place
to
put
into
headers
– Refresh
semanLcs
– If
you
offer
a
long-‐lived
key
then
ignore
refresh
22. What
is
OpenID
Connect
• A
well-‐defined
pabern
for
using
OAuth2
for
idenLty
– A
pre-‐defined
scope
– A
well-‐defined
REST
API
for
user
info
– A
discovery
model
• My
predicLon:
– Widespread
adopLon
25. Ecosystems
• Allow
smaller
organizaLons
to
compete
effecLvely
– Be
more
agile,
nimble
• Allow
larger
organizaLons
to
compete
more
effecLvely
– By
working
with
smaller,
more
agile
partners!
• Enable
“best-‐of-‐breed”
capabiliLes
to
conjoin
to
create
beber
soluLons
• Take
advantage
of
APIs
and
promote
APIs
– A
virtuous
circle
26. The
wider
sense
of
virtualizaLon
Automation
}
Control
Monitoring
Import
org.apache.x
Agility
Flexibility
27. APIs
and
PaaS
• APIs
are
the
virtualizaLon
of
funcLon
• PaaS
is
the
virtualizaLon
of
applicaLon
deployment
• App
Factory
is
the
virtualizaLon
of
development
• Together
this
is
basis
for
the
virtualizaLon
of
an
ecosystem
28. Summary
• Build
an
API
strategy
that
revolves
around:
– CreaLng
or
parLcipaLng
in
an
ecosystem
– Giving
API
consumers
the
tools
and
capabiliLes
they
need
– By
being
agile
and
responsive
– And
using
the
right
technologies
