APIs : Mapping the way

740 views
594 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
740
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
38
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

APIs : Mapping the way

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

×