SlideShare a Scribd company logo
1 of 28
Download to read offline
Is	
  Your	
  API	
  Naked?	
  
API	
  Technology	
  &	
  Opera:ons	
  
Rapid	
  API	
  Workshop	
  


Greg	
  Brail 	
  	
  	
  	
  @gbrail	
  
Brian	
  Mulloy	
  	
  	
  @landlessness	
  
@landlessness   @gbrail
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	
  
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	
  
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
API	
  Management	
  Technology	
  
                  Considera>ons	
  vs.	
  Lifecycle	
  
                                                                 Performance	
  and	
  Scale	
  

                                           Traffic	
  Management	
  

                   Secure	
  Access	
  

                  Analy>cs	
  

                   Developer	
  Enablement	
  




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	
  

                                         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?	
  
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

 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	
  
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?	
  	
             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	
  
Content	
  vs.	
  Transac>onal	
  APIs	
  
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	
  
THANK	
  YOU	
  
	
          	
  
Ques%ons	
  and	
  ideas	
  to:
@gbrail	
  
@landlessness	
  
@apigee	
  

More Related Content

Viewers also liked

ICIC 2014 Application Programming Interface (API) Technologies to Integrate C...
ICIC 2014 Application Programming Interface (API) Technologies to Integrate C...ICIC 2014 Application Programming Interface (API) Technologies to Integrate C...
ICIC 2014 Application Programming Interface (API) Technologies to Integrate C...Dr. Haxel Consult
 
RF Circuit Design - [Ch4-1] Microwave Transistor Amplifier
RF Circuit Design - [Ch4-1] Microwave Transistor AmplifierRF Circuit Design - [Ch4-1] Microwave Transistor Amplifier
RF Circuit Design - [Ch4-1] Microwave Transistor AmplifierSimen Li
 
Your API Sucks! Why developers hang up and how to stop that.
Your API Sucks! Why developers hang up and how to stop that.Your API Sucks! Why developers hang up and how to stop that.
Your API Sucks! Why developers hang up and how to stop that.Apigee | Google Cloud
 
Mapping out your API Strategy - 4.20.11 Webinar slides
Mapping out your API Strategy - 4.20.11 Webinar slidesMapping out your API Strategy - 4.20.11 Webinar slides
Mapping out your API Strategy - 4.20.11 Webinar slidesApigee | Google Cloud
 
Pragmatic RESTful API Design: Apigee Webinar
Pragmatic RESTful API Design: Apigee WebinarPragmatic RESTful API Design: Apigee Webinar
Pragmatic RESTful API Design: Apigee WebinarApigee | Google Cloud
 
10 patterns in successful api programs 2
10 patterns in successful api programs 210 patterns in successful api programs 2
10 patterns in successful api programs 2Apigee | Google Cloud
 
API Product Management - Driving Success through the Value Chain
API Product Management - Driving Success through the Value ChainAPI Product Management - Driving Success through the Value Chain
API Product Management - Driving Success through the Value ChainApigee | Google Cloud
 
[Military] [article] [armada international] land based air defence
[Military] [article] [armada international] land based air defence[Military] [article] [armada international] land based air defence
[Military] [article] [armada international] land based air defencezerliz3
 
Synthesis of Linear and Non-Separable Planar Array Patterns
Synthesis of Linear and Non-Separable Planar Array PatternsSynthesis of Linear and Non-Separable Planar Array Patterns
Synthesis of Linear and Non-Separable Planar Array PatternsMichael Buckley
 
Colfax-Winograd-Summary _final (1)
Colfax-Winograd-Summary _final (1)Colfax-Winograd-Summary _final (1)
Colfax-Winograd-Summary _final (1)Sangamesh Ragate
 
Working with informtiaca teradata parallel transporter
Working with informtiaca teradata parallel transporterWorking with informtiaca teradata parallel transporter
Working with informtiaca teradata parallel transporterAnjaneyulu Gunti
 
FY15 COCOMs Sales Opportunities
FY15 COCOMs Sales OpportunitiesFY15 COCOMs Sales Opportunities
FY15 COCOMs Sales OpportunitiesimmixGroup
 
DLT Solutions interview questions and answers
DLT Solutions interview questions and answersDLT Solutions interview questions and answers
DLT Solutions interview questions and answersgetbrid665
 
ERRP=Addendum to resettlement action plan - package - 2 & 3
ERRP=Addendum to resettlement action plan - package - 2 & 3ERRP=Addendum to resettlement action plan - package - 2 & 3
ERRP=Addendum to resettlement action plan - package - 2 & 3zubeditufail
 
Voltage controlled oscillators
Voltage controlled oscillatorsVoltage controlled oscillators
Voltage controlled oscillatorsZunAib Ali
 
Frederick County Office of Economic Development 2015 Annual Report
Frederick County Office of Economic Development 2015 Annual ReportFrederick County Office of Economic Development 2015 Annual Report
Frederick County Office of Economic Development 2015 Annual ReportSandy Wagerman
 
GTRI Splunk Overview - Splunk Tech Day
GTRI Splunk Overview - Splunk Tech DayGTRI Splunk Overview - Splunk Tech Day
GTRI Splunk Overview - Splunk Tech DayZivaro Inc
 
World Wide Technology Tec37 Webinar - Deploy and Manage Windows 10 at Scale v1
World Wide Technology Tec37 Webinar -  Deploy and Manage Windows 10 at Scale v1World Wide Technology Tec37 Webinar -  Deploy and Manage Windows 10 at Scale v1
World Wide Technology Tec37 Webinar - Deploy and Manage Windows 10 at Scale v1World Wide Technology
 
GFS Chemicals Introduction
GFS Chemicals IntroductionGFS Chemicals Introduction
GFS Chemicals IntroductionGFS Chemicals
 

Viewers also liked (20)

ICIC 2014 Application Programming Interface (API) Technologies to Integrate C...
ICIC 2014 Application Programming Interface (API) Technologies to Integrate C...ICIC 2014 Application Programming Interface (API) Technologies to Integrate C...
ICIC 2014 Application Programming Interface (API) Technologies to Integrate C...
 
RF Circuit Design - [Ch4-1] Microwave Transistor Amplifier
RF Circuit Design - [Ch4-1] Microwave Transistor AmplifierRF Circuit Design - [Ch4-1] Microwave Transistor Amplifier
RF Circuit Design - [Ch4-1] Microwave Transistor Amplifier
 
Your API Sucks! Why developers hang up and how to stop that.
Your API Sucks! Why developers hang up and how to stop that.Your API Sucks! Why developers hang up and how to stop that.
Your API Sucks! Why developers hang up and how to stop that.
 
Mapping out your API Strategy - 4.20.11 Webinar slides
Mapping out your API Strategy - 4.20.11 Webinar slidesMapping out your API Strategy - 4.20.11 Webinar slides
Mapping out your API Strategy - 4.20.11 Webinar slides
 
Pragmatic RESTful API Design: Apigee Webinar
Pragmatic RESTful API Design: Apigee WebinarPragmatic RESTful API Design: Apigee Webinar
Pragmatic RESTful API Design: Apigee Webinar
 
10 patterns in successful api programs 2
10 patterns in successful api programs 210 patterns in successful api programs 2
10 patterns in successful api programs 2
 
API Product Management - Driving Success through the Value Chain
API Product Management - Driving Success through the Value ChainAPI Product Management - Driving Success through the Value Chain
API Product Management - Driving Success through the Value Chain
 
[Military] [article] [armada international] land based air defence
[Military] [article] [armada international] land based air defence[Military] [article] [armada international] land based air defence
[Military] [article] [armada international] land based air defence
 
Synthesis of Linear and Non-Separable Planar Array Patterns
Synthesis of Linear and Non-Separable Planar Array PatternsSynthesis of Linear and Non-Separable Planar Array Patterns
Synthesis of Linear and Non-Separable Planar Array Patterns
 
Colfax-Winograd-Summary _final (1)
Colfax-Winograd-Summary _final (1)Colfax-Winograd-Summary _final (1)
Colfax-Winograd-Summary _final (1)
 
Working with informtiaca teradata parallel transporter
Working with informtiaca teradata parallel transporterWorking with informtiaca teradata parallel transporter
Working with informtiaca teradata parallel transporter
 
FY15 COCOMs Sales Opportunities
FY15 COCOMs Sales OpportunitiesFY15 COCOMs Sales Opportunities
FY15 COCOMs Sales Opportunities
 
DLT Solutions interview questions and answers
DLT Solutions interview questions and answersDLT Solutions interview questions and answers
DLT Solutions interview questions and answers
 
Swati Dubey QA 6 Yrs
Swati Dubey QA 6 YrsSwati Dubey QA 6 Yrs
Swati Dubey QA 6 Yrs
 
ERRP=Addendum to resettlement action plan - package - 2 & 3
ERRP=Addendum to resettlement action plan - package - 2 & 3ERRP=Addendum to resettlement action plan - package - 2 & 3
ERRP=Addendum to resettlement action plan - package - 2 & 3
 
Voltage controlled oscillators
Voltage controlled oscillatorsVoltage controlled oscillators
Voltage controlled oscillators
 
Frederick County Office of Economic Development 2015 Annual Report
Frederick County Office of Economic Development 2015 Annual ReportFrederick County Office of Economic Development 2015 Annual Report
Frederick County Office of Economic Development 2015 Annual Report
 
GTRI Splunk Overview - Splunk Tech Day
GTRI Splunk Overview - Splunk Tech DayGTRI Splunk Overview - Splunk Tech Day
GTRI Splunk Overview - Splunk Tech Day
 
World Wide Technology Tec37 Webinar - Deploy and Manage Windows 10 at Scale v1
World Wide Technology Tec37 Webinar -  Deploy and Manage Windows 10 at Scale v1World Wide Technology Tec37 Webinar -  Deploy and Manage Windows 10 at Scale v1
World Wide Technology Tec37 Webinar - Deploy and Manage Windows 10 at Scale v1
 
GFS Chemicals Introduction
GFS Chemicals IntroductionGFS Chemicals Introduction
GFS Chemicals Introduction
 

Similar to Is your API Naked? API Technology and Ops Considerations: Webinar slides

APIdays Paris 2018 - Creating an API economy business strategy Alan Glickenho...
APIdays Paris 2018 - Creating an API economy business strategy Alan Glickenho...APIdays Paris 2018 - Creating an API economy business strategy Alan Glickenho...
APIdays Paris 2018 - Creating an API economy business strategy Alan Glickenho...apidays
 
Api management introduction and product overview v1.0 2014.08.28
Api management introduction and product overview v1.0 2014.08.28Api management introduction and product overview v1.0 2014.08.28
Api management introduction and product overview v1.0 2014.08.28floridawusergroup
 
Hewlett Packard Enterprise View on Going Big with API Management - Applicatio...
Hewlett Packard Enterprise View on Going Big with API Management - Applicatio...Hewlett Packard Enterprise View on Going Big with API Management - Applicatio...
Hewlett Packard Enterprise View on Going Big with API Management - Applicatio...CA Technologies
 
API Frenzy: API Strategy 101
API Frenzy: API Strategy 101API Frenzy: API Strategy 101
API Frenzy: API Strategy 101Akana
 
API Frenzy: API Strategy 101
API Frenzy: API Strategy 101API Frenzy: API Strategy 101
API Frenzy: API Strategy 101Akana
 
apidays LIVE LONDON - API platform strategy and operating models by Kiran Nadgir
apidays LIVE LONDON - API platform strategy and operating models by Kiran Nadgirapidays LIVE LONDON - API platform strategy and operating models by Kiran Nadgir
apidays LIVE LONDON - API platform strategy and operating models by Kiran Nadgirapidays
 
#1922 rest-push2 ap-im-v6
#1922 rest-push2 ap-im-v6#1922 rest-push2 ap-im-v6
#1922 rest-push2 ap-im-v6Jack Carnes
 
[WSO2 Summit Americas 2020] Having the Best Technology Isn’t Everything
[WSO2 Summit Americas 2020] Having the Best Technology Isn’t Everything[WSO2 Summit Americas 2020] Having the Best Technology Isn’t Everything
[WSO2 Summit Americas 2020] Having the Best Technology Isn’t EverythingWSO2
 
Lectura 2.4 is your api naked - 10 roadmap considerations
Lectura 2.4   is your api naked - 10 roadmap considerationsLectura 2.4   is your api naked - 10 roadmap considerations
Lectura 2.4 is your api naked - 10 roadmap considerationsMatias Menendez
 
IWMW 2000: Self Evident Applications for Universities
IWMW 2000: Self Evident Applications for UniversitiesIWMW 2000: Self Evident Applications for Universities
IWMW 2000: Self Evident Applications for UniversitiesIWMW
 
SAP API Management sap insider webinar intelligent business operations netw...
SAP API Management   sap insider webinar intelligent business operations netw...SAP API Management   sap insider webinar intelligent business operations netw...
SAP API Management sap insider webinar intelligent business operations netw...Darren Crowder
 
Publishing Your First Paid App on AppExchange: The Inside Scoop
Publishing Your First Paid App on AppExchange: The Inside ScoopPublishing Your First Paid App on AppExchange: The Inside Scoop
Publishing Your First Paid App on AppExchange: The Inside ScoopSalesforce Developers
 
API Management point of view
API Management point of viewAPI Management point of view
API Management point of viewRavish Adka Rao
 
IBM API management Philip Little
IBM API management Philip LittleIBM API management Philip Little
IBM API management Philip LittleValeri Illescas
 
API Management in Digital Transformation
API Management in Digital TransformationAPI Management in Digital Transformation
API Management in Digital TransformationAditya Thatte
 
apidays LIVE Hong Kong - The Future of Legacy - How to leverage legacy and on...
apidays LIVE Hong Kong - The Future of Legacy - How to leverage legacy and on...apidays LIVE Hong Kong - The Future of Legacy - How to leverage legacy and on...
apidays LIVE Hong Kong - The Future of Legacy - How to leverage legacy and on...apidays
 
APIs as a Product Strategy
APIs as a Product StrategyAPIs as a Product Strategy
APIs as a Product StrategyRavi Kumar
 
6 key things UXers need to know while working with APIs
6 key things UXers need to know while working with APIs6 key things UXers need to know while working with APIs
6 key things UXers need to know while working with APIsMargaret Hanley
 

Similar to Is your API Naked? API Technology and Ops Considerations: Webinar slides (20)

APIdays Paris 2018 - Creating an API economy business strategy Alan Glickenho...
APIdays Paris 2018 - Creating an API economy business strategy Alan Glickenho...APIdays Paris 2018 - Creating an API economy business strategy Alan Glickenho...
APIdays Paris 2018 - Creating an API economy business strategy Alan Glickenho...
 
Api management introduction and product overview v1.0 2014.08.28
Api management introduction and product overview v1.0 2014.08.28Api management introduction and product overview v1.0 2014.08.28
Api management introduction and product overview v1.0 2014.08.28
 
Hewlett Packard Enterprise View on Going Big with API Management - Applicatio...
Hewlett Packard Enterprise View on Going Big with API Management - Applicatio...Hewlett Packard Enterprise View on Going Big with API Management - Applicatio...
Hewlett Packard Enterprise View on Going Big with API Management - Applicatio...
 
API Frenzy: API Strategy 101
API Frenzy: API Strategy 101API Frenzy: API Strategy 101
API Frenzy: API Strategy 101
 
API Frenzy: API Strategy 101
API Frenzy: API Strategy 101API Frenzy: API Strategy 101
API Frenzy: API Strategy 101
 
Smartone v1.0
Smartone v1.0Smartone v1.0
Smartone v1.0
 
apidays LIVE LONDON - API platform strategy and operating models by Kiran Nadgir
apidays LIVE LONDON - API platform strategy and operating models by Kiran Nadgirapidays LIVE LONDON - API platform strategy and operating models by Kiran Nadgir
apidays LIVE LONDON - API platform strategy and operating models by Kiran Nadgir
 
#1922 rest-push2 ap-im-v6
#1922 rest-push2 ap-im-v6#1922 rest-push2 ap-im-v6
#1922 rest-push2 ap-im-v6
 
[WSO2 Summit Americas 2020] Having the Best Technology Isn’t Everything
[WSO2 Summit Americas 2020] Having the Best Technology Isn’t Everything[WSO2 Summit Americas 2020] Having the Best Technology Isn’t Everything
[WSO2 Summit Americas 2020] Having the Best Technology Isn’t Everything
 
Lectura 2.4 is your api naked - 10 roadmap considerations
Lectura 2.4   is your api naked - 10 roadmap considerationsLectura 2.4   is your api naked - 10 roadmap considerations
Lectura 2.4 is your api naked - 10 roadmap considerations
 
IWMW 2000: Self Evident Applications for Universities
IWMW 2000: Self Evident Applications for UniversitiesIWMW 2000: Self Evident Applications for Universities
IWMW 2000: Self Evident Applications for Universities
 
SAP API Management sap insider webinar intelligent business operations netw...
SAP API Management   sap insider webinar intelligent business operations netw...SAP API Management   sap insider webinar intelligent business operations netw...
SAP API Management sap insider webinar intelligent business operations netw...
 
Publishing Your First Paid App on AppExchange: The Inside Scoop
Publishing Your First Paid App on AppExchange: The Inside ScoopPublishing Your First Paid App on AppExchange: The Inside Scoop
Publishing Your First Paid App on AppExchange: The Inside Scoop
 
Effective API Design
Effective API DesignEffective API Design
Effective API Design
 
API Management point of view
API Management point of viewAPI Management point of view
API Management point of view
 
IBM API management Philip Little
IBM API management Philip LittleIBM API management Philip Little
IBM API management Philip Little
 
API Management in Digital Transformation
API Management in Digital TransformationAPI Management in Digital Transformation
API Management in Digital Transformation
 
apidays LIVE Hong Kong - The Future of Legacy - How to leverage legacy and on...
apidays LIVE Hong Kong - The Future of Legacy - How to leverage legacy and on...apidays LIVE Hong Kong - The Future of Legacy - How to leverage legacy and on...
apidays LIVE Hong Kong - The Future of Legacy - How to leverage legacy and on...
 
APIs as a Product Strategy
APIs as a Product StrategyAPIs as a Product Strategy
APIs as a Product Strategy
 
6 key things UXers need to know while working with APIs
6 key things UXers need to know while working with APIs6 key things UXers need to know while working with APIs
6 key things UXers need to know while working with APIs
 

More from Apigee | Google Cloud

Monetization: Unlock More Value from Your APIs
Monetization: Unlock More Value from Your APIs Monetization: Unlock More Value from Your APIs
Monetization: Unlock More Value from Your APIs Apigee | Google Cloud
 
AccuWeather: Recasting API Experiences in a Developer-First World
AccuWeather: Recasting API Experiences in a Developer-First WorldAccuWeather: Recasting API Experiences in a Developer-First World
AccuWeather: Recasting API Experiences in a Developer-First WorldApigee | Google Cloud
 
Which Application Modernization Pattern Is Right For You?
Which Application Modernization Pattern Is Right For You?Which Application Modernization Pattern Is Right For You?
Which Application Modernization Pattern Is Right For You?Apigee | Google Cloud
 
The Four Transformative Forces of the API Management Market
The Four Transformative Forces of the API Management MarketThe Four Transformative Forces of the API Management Market
The Four Transformative Forces of the API Management MarketApigee | Google Cloud
 
Managing the Complexity of Microservices Deployments
Managing the Complexity of Microservices DeploymentsManaging the Complexity of Microservices Deployments
Managing the Complexity of Microservices DeploymentsApigee | Google Cloud
 
Microservices Done Right: Key Ingredients for Microservices Success
Microservices Done Right: Key Ingredients for Microservices SuccessMicroservices Done Right: Key Ingredients for Microservices Success
Microservices Done Right: Key Ingredients for Microservices SuccessApigee | Google Cloud
 
Adapt or Die: Opening Keynote with Chet Kapoor
Adapt or Die: Opening Keynote with Chet KapoorAdapt or Die: Opening Keynote with Chet Kapoor
Adapt or Die: Opening Keynote with Chet KapoorApigee | Google Cloud
 
Adapt or Die: Keynote with Greg Brail
Adapt or Die: Keynote with Greg BrailAdapt or Die: Keynote with Greg Brail
Adapt or Die: Keynote with Greg BrailApigee | Google Cloud
 
Adapt or Die: Keynote with Anant Jhingran
Adapt or Die: Keynote with Anant JhingranAdapt or Die: Keynote with Anant Jhingran
Adapt or Die: Keynote with Anant JhingranApigee | Google Cloud
 
London Adapt or Die: Closing Keynote — Adapt Now!
London Adapt or Die: Closing Keynote — Adapt Now!London Adapt or Die: Closing Keynote — Adapt Now!
London Adapt or Die: Closing Keynote — Adapt Now!Apigee | Google Cloud
 

More from Apigee | Google Cloud (20)

How Secure Are Your APIs?
How Secure Are Your APIs?How Secure Are Your APIs?
How Secure Are Your APIs?
 
Magazine Luiza at a glance (1)
Magazine Luiza at a glance (1)Magazine Luiza at a glance (1)
Magazine Luiza at a glance (1)
 
Monetization: Unlock More Value from Your APIs
Monetization: Unlock More Value from Your APIs Monetization: Unlock More Value from Your APIs
Monetization: Unlock More Value from Your APIs
 
Apigee Demo: API Platform Overview
Apigee Demo: API Platform OverviewApigee Demo: API Platform Overview
Apigee Demo: API Platform Overview
 
Ticketmaster at a glance
Ticketmaster at a glanceTicketmaster at a glance
Ticketmaster at a glance
 
AccuWeather: Recasting API Experiences in a Developer-First World
AccuWeather: Recasting API Experiences in a Developer-First WorldAccuWeather: Recasting API Experiences in a Developer-First World
AccuWeather: Recasting API Experiences in a Developer-First World
 
Which Application Modernization Pattern Is Right For You?
Which Application Modernization Pattern Is Right For You?Which Application Modernization Pattern Is Right For You?
Which Application Modernization Pattern Is Right For You?
 
Apigee Product Roadmap Part 2
Apigee Product Roadmap Part 2Apigee Product Roadmap Part 2
Apigee Product Roadmap Part 2
 
The Four Transformative Forces of the API Management Market
The Four Transformative Forces of the API Management MarketThe Four Transformative Forces of the API Management Market
The Four Transformative Forces of the API Management Market
 
Walgreens at a glance
Walgreens at a glanceWalgreens at a glance
Walgreens at a glance
 
Apigee Edge: Intro to Microgateway
Apigee Edge: Intro to MicrogatewayApigee Edge: Intro to Microgateway
Apigee Edge: Intro to Microgateway
 
Managing the Complexity of Microservices Deployments
Managing the Complexity of Microservices DeploymentsManaging the Complexity of Microservices Deployments
Managing the Complexity of Microservices Deployments
 
Pitney Bowes at a glance
Pitney Bowes at a glancePitney Bowes at a glance
Pitney Bowes at a glance
 
Microservices Done Right: Key Ingredients for Microservices Success
Microservices Done Right: Key Ingredients for Microservices SuccessMicroservices Done Right: Key Ingredients for Microservices Success
Microservices Done Right: Key Ingredients for Microservices Success
 
Adapt or Die: Opening Keynote with Chet Kapoor
Adapt or Die: Opening Keynote with Chet KapoorAdapt or Die: Opening Keynote with Chet Kapoor
Adapt or Die: Opening Keynote with Chet Kapoor
 
Adapt or Die: Keynote with Greg Brail
Adapt or Die: Keynote with Greg BrailAdapt or Die: Keynote with Greg Brail
Adapt or Die: Keynote with Greg Brail
 
Adapt or Die: Keynote with Anant Jhingran
Adapt or Die: Keynote with Anant JhingranAdapt or Die: Keynote with Anant Jhingran
Adapt or Die: Keynote with Anant Jhingran
 
London Adapt or Die: Opening Keynot
London Adapt or Die: Opening KeynotLondon Adapt or Die: Opening Keynot
London Adapt or Die: Opening Keynot
 
London Adapt or Die: Lunch keynote
London Adapt or Die: Lunch keynoteLondon Adapt or Die: Lunch keynote
London Adapt or Die: Lunch keynote
 
London Adapt or Die: Closing Keynote — Adapt Now!
London Adapt or Die: Closing Keynote — Adapt Now!London Adapt or Die: Closing Keynote — Adapt Now!
London Adapt or Die: Closing Keynote — Adapt Now!
 

Recently uploaded

Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-pyJamie (Taka) Wang
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfJamie (Taka) Wang
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 

Recently uploaded (20)

Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-py
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
20230104 - machine vision
20230104 - machine vision20230104 - machine vision
20230104 - machine vision
 

Is your API Naked? API Technology and Ops Considerations: Webinar slides

  • 1. Is  Your  API  Naked?   API  Technology  &  Opera:ons   Rapid  API  Workshop   Greg  Brail        @gbrail   Brian  Mulloy      @landlessness  
  • 2. @landlessness @gbrail
  • 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