Is  Your  API  Naked?  API  Technology  &  Opera:ons  

Rapid  API  Workshop  

Greg  Brail        @gbrail  

Brian  Mulloy      @landlessness  

@landlessness @gbrail

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  

Rapid API Workshop Webinar Series

Roadmap  Considera>ons  1.  Can  You  See  It?    

–  API  Visibility  2.  Don’t  have  a  Meltdown    

–  API  Traffic  Management  3.  Keys  to  Your  Kingdom    

–  API  Iden>ty,  Authen>ca>on,  and  Authoriza>on  

4.  Don’t  Roll  Your  Own    –  API  Security  

5.  Indecent  Exposure    –  API  Data  Protec>on  

6.  Some  Things  Will  Change    –  API  Versioning  

7.  Welcome  Aboard!  –  API  User  Management  

8.  Field  of  Dreams  –  API  Community  and  

Audience  9.  Show  Me  the  Money  

–  API  Mone>za>on  10.   Pump  Up  the  Volume  

–  API  Scalability  

API  Lifecycle  

Curious   Building   Launching   Growing   Expanding  

•  Requirements •  Business case •  Prototyping

•  API design •  Policy design •  Development

•  Beta customers •  Rapid iteration •  Driving adoption

•  Scaling API •  Scaling processes •  Managing growth

•  New capabilities •  New markets •  Tiered policies

API  Management  Technology  Considera>ons  vs.  Lifecycle  

Developer  Enablement  

Secure  Access  

Analy>cs  

Traffic  Management  

Performance  and  Scale  

Curious   Building   Launching   Growing   Expanding  

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  

API  Visibility  

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?  

1.  Can  You  See  It?  

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  

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?    

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  

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?  

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?  

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  

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  –  Replay  aGacks:  re-­‐sending  intercepted  valid  data,  possibly  including  altera>on  of  some  fields  

Data  masking  –  preven>ng  inadvertent  data  exposure  in  API  responses  –  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  

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  

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?    

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?    

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?    

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  

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?  

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?  

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  

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?  

What  We  Covered  1.  Can  You  See  It?    

–  API  Visibility  2.  Don’t  have  a  Meltdown    

–  API  Traffic  Management  3.  Keys  to  Your  Kingdom    

–  API  Iden>ty,  Authen>ca>on,  and  Authoriza>on  

4.  Don’t  Roll  Your  Own    –  API  Security  

5.  Indecent  Exposure    –  API  Data  Protec>on  

6.  Some  Things  Will  Change    –  API  Versioning  

7.  Welcome  Aboard!  –  API  User  Management  

8.  Field  of  Dreams  –  API  Community  and  

Audience  9.  Show  Me  the  Money  

–  API  Mone>za>on  10.   Pump  Up  the  Volume  

–  API  Scalability  

Content  vs.  Transac>onal  APIs  

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  

Rapid API Workshop Webinar Series

THANK  YOU    Ques%ons  and  ideas  to:  @gbrail  @landlessness  @apigee