Scalabay - API Design Antipatterns

95
API An&pa)erns …iden&fying, and avoiding them Manish Pandit @lobster1234
  • date post

    19-Oct-2014
  • Category

    Technology

  • view

    243
  • download

    2

description

Slides from my talk on API Design Patterns at ScalaBay Meetup at Netflix on 09/09/2014. http://www.meetup.com/Scala-Bay/events/195982742/

Transcript of Scalabay - API Design Antipatterns

Page 1: Scalabay - API Design Antipatterns

API  An&pa)erns  …iden&fying,  and  avoiding  them  

 

Manish Pandit @lobster1234

Page 2: Scalabay - API Design Antipatterns

 Manish  Pandit  @lobster1234  

mpandit  at  neAlix  dot  com    

linkedin.com/in/mpandit  slideshare.net/lobster1234  

@lobster1234

Page 3: Scalabay - API Design Antipatterns

APIs  

   

A  means  for  soGware  to  interact  with  other  soGware.  

@lobster1234

Page 4: Scalabay - API Design Antipatterns

   

@lobster1234

Page 5: Scalabay - API Design Antipatterns

@lobster1234

Image  Credit:  h)p://en.wikipedia.org/wiki/Internet_of_Things  

Page 6: Scalabay - API Design Antipatterns

@lobster1234

Page 7: Scalabay - API Design Antipatterns

REST  API  

REST  is  not  a  standard,  but  an  architecture    

@lobster1234

Page 8: Scalabay - API Design Antipatterns

REST  API  

REST  is  not  a  standard,  but  an  architecture,  which  uses  HTTP  as  a  model  for  all  interac.ons.  

 If  HTTP  is  a  standard,  REST  is  a  conven&on.  

@lobster1234

Page 9: Scalabay - API Design Antipatterns

@lobster1234

Page 10: Scalabay - API Design Antipatterns

REST  API  

 Noun  è  Resource,  or  the  En&ty  

 Verb  è  Ac&on  

+  Iden.fier    

@lobster1234

Page 11: Scalabay - API Design Antipatterns

Image:  h)p://www.educa&on.com/study-­‐help/ar&cle/nouns/    

@lobster1234

Page 12: Scalabay - API Design Antipatterns

Protocol  

   

May  or  may  not  be  standard  

@lobster1234

Page 13: Scalabay - API Design Antipatterns

Protocol  

     

May  or  may  not  be  standard  Indicates  an  agreement  between  the  par&es  

   

@lobster1234

Page 14: Scalabay - API Design Antipatterns

@lobster1234

Page 15: Scalabay - API Design Antipatterns

Payload  

     

Format  (XML,  JSON,  Custom  Text,  Binary..)    

Transport  (HTTP,  Binary  over  sockets,  FTP..)  

@lobster1234

Page 16: Scalabay - API Design Antipatterns

   

@lobster1234

Page 17: Scalabay - API Design Antipatterns

   h)p://www.neAlix.com/header/neAlix_logo.gif    Or,  reques.ng  a  resource  from  the  server  by  

giving  its  path  using  a  protocol.  

@lobster1234

Page 18: Scalabay - API Design Antipatterns

Every  request  deserves  a  response.  

@lobster1234

Page 19: Scalabay - API Design Antipatterns

Headers  describe  the  response  

@lobster1234

Page 20: Scalabay - API Design Antipatterns

Headers  describe  the  response    

Status  Code  indicates  the  success/failure  

@lobster1234

Page 21: Scalabay - API Design Antipatterns

 Headers  describe  the  response  

 Status  Code  indicates  the  success/failure  

 Body  contains  the  actual  payload  

@lobster1234

Page 22: Scalabay - API Design Antipatterns

   

Tell  the  server  what  to  do  via  ac.ons  

@lobster1234

Page 23: Scalabay - API Design Antipatterns

   Ac&ons  are  HTTP  methods,  which  map  nicely  to  

(most  of)  the  business  interac&ons  

@lobster1234

Page 24: Scalabay - API Design Antipatterns

 Create  –  POST  Read  –  GET  

Update  –  PUT  (or  PATCH)  Delete  -­‐  DELETE  

 HEAD,  OPTIONS,  TRACE,  CONNECT  

@lobster1234

Page 25: Scalabay - API Design Antipatterns

Pa)erns  

@lobster1234

Page 26: Scalabay - API Design Antipatterns

Pa)erns  

Pa)erns  are  re-­‐usable  solu&ons  to  commonly  occurring  problems.  

@lobster1234

Page 27: Scalabay - API Design Antipatterns

Common  Scenarios  

   

Gebng  data  from  the  server      

@lobster1234

Page 28: Scalabay - API Design Antipatterns

Common  Scenarios  

   

Gebng  data  from  the  server    

Sending  data  to  the  server    

@lobster1234

Page 29: Scalabay - API Design Antipatterns

An&pa)erns  

     

An&pa)erns  are  re-­‐usable  solu&ons  to    commonly  occurring  problems,  that  look  great  on  the  surface,  but  

really  aren’t.  

 

@lobster1234

Page 30: Scalabay - API Design Antipatterns

   

Request  An&pa)erns  

@lobster1234

Page 31: Scalabay - API Design Antipatterns

   

Over-­‐using  Query  Strings  

@lobster1234

Page 32: Scalabay - API Design Antipatterns

   

/pets?name=scruffy  vs.  

/pets/name/scruffy  

@lobster1234

Page 33: Scalabay - API Design Antipatterns

   

/pets?name=scruffy&zip=94568  vs.  

/pets/name/scruffy/loca&on/zip/94568  

@lobster1234

Page 34: Scalabay - API Design Antipatterns

     

Avoid  query  strings  for  resource  iden&fica&on  But  use  them  for  request  metadata  *  

   

*Except  for  search  

@lobster1234

Page 35: Scalabay - API Design Antipatterns

   

Pagina&on  Filtering  Sor&ng  

..  

@lobster1234

Page 36: Scalabay - API Design Antipatterns

@lobster1234

Page 37: Scalabay - API Design Antipatterns

Query  Strings  

 h)p://some.api.com/movies?start=0&count=10&sortBy=name&fields=name,cast,releaseDate  

@lobster1234

Page 38: Scalabay - API Design Antipatterns

   

Allowing  clients  to  scrape  the  data  via  your  APIs  

@lobster1234

Page 39: Scalabay - API Design Antipatterns

@lobster1234

Page 40: Scalabay - API Design Antipatterns

   

Think  batch  jobs  reques&ng  the  catalog  nightly!  

@lobster1234

Page 41: Scalabay - API Design Antipatterns

   

Request  metadata  to  the  rescue?  

@lobster1234

Page 42: Scalabay - API Design Antipatterns

     

….how  about  a  ?since=1d    

…or  ?since=UTC  

@lobster1234

Page 43: Scalabay - API Design Antipatterns

   

Method  An&pa)erns  

@lobster1234

Page 44: Scalabay - API Design Antipatterns

   

Using  Query  Strings  to  overload  verbs  

@lobster1234

Page 45: Scalabay - API Design Antipatterns

     

/pets?perform=update&name=scruffy&id=24  

@lobster1234

Page 46: Scalabay - API Design Antipatterns

     

Use  the  appropriate  HTTP  Method  to  represent  your  ac&on  

 

@lobster1234

Page 47: Scalabay - API Design Antipatterns

   

Using  POST  for  all  writes  

@lobster1234

Page 48: Scalabay - API Design Antipatterns

     

GET  to  retrieve,  or  search  POST  to  create,  or  upsert  

PUT  to  update  (or  be)er  yet,  PATCH)  DELETE  to  delete  

@lobster1234

Page 49: Scalabay - API Design Antipatterns

   Using  HTTP  PUT  or  POST  to  set  a  value  to  null  

@lobster1234

Page 50: Scalabay - API Design Antipatterns

Updates  vs.  Deletes  

 Everything  works  when  there  is  data,  but  what  

when  there  is  no  data..?  

@lobster1234

Page 51: Scalabay - API Design Antipatterns

   

 Use  HTTP  DELETE  to  set  a  value  to  null  

 Remember,  we  have  a  path  to  not  just  the  resource,  but  also  it’s  

a)ributes  

@lobster1234

Page 52: Scalabay - API Design Antipatterns

   

 DELETE  /pets/<id>/collartag  

   

@lobster1234

Page 53: Scalabay - API Design Antipatterns

   

Response  An&pa)erns  

@lobster1234

Page 54: Scalabay - API Design Antipatterns

   

Always  returning  HTTP  200  

@lobster1234

Page 55: Scalabay - API Design Antipatterns

@lobster1234

Page 56: Scalabay - API Design Antipatterns

HTTP  200  OK    

{  “success”  :  false  }  

@lobster1234

Page 57: Scalabay - API Design Antipatterns

HTTP  200  OK    

{  “error”  :  ”Person  jdoe  not  found”  }  

@lobster1234

Page 58: Scalabay - API Design Antipatterns

 

 

2xx  for  success  3xx  for  redirects/caching  

4xx  for  request/client  errors  5xx  for  server  errors  

@lobster1234

Page 59: Scalabay - API Design Antipatterns

Some  Useful  (and  not  so  common)  Codes    

Return  aGer  a  delete  -­‐  204  Failed  database  constraint  -­‐  409  Method  not  supported  -­‐  405  

Trying  to  ask  for  too  much  data  -­‐  413  Valida&on  Failure  -­‐  418  

@lobster1234

Page 60: Scalabay - API Design Antipatterns

 Always  returning  a  401  for  auth  failures  

   

Page 61: Scalabay - API Design Antipatterns

@lobster1234

Page 62: Scalabay - API Design Antipatterns

Auth  

     

Use  HTTP  401  Unauthorized  to  indicate  that  the  client  needs  to  authen&cate  

@lobster1234

Page 63: Scalabay - API Design Antipatterns

Auth  

     

Use  HTTP  403  Forbidden  to  indicate  that  the  client’s  creden&als  do  not  allow  access  to  the  

requested  resource  

@lobster1234

Page 64: Scalabay - API Design Antipatterns

401  vs  403  

   

401  =  Come  back  with  a  key    

403  =  Your  key  does  not  work  for  this  lock.  

@lobster1234

Page 65: Scalabay - API Design Antipatterns

 Processing  requests  synchronously,  even  &me  

intensive  ones    

@lobster1234

Page 66: Scalabay - API Design Antipatterns

     

Async  the  opera&on,  and  return    HTTP  202  –  Accepted  

   

@lobster1234

Page 67: Scalabay - API Design Antipatterns

@lobster1234

Page 68: Scalabay - API Design Antipatterns

 Async  opera&on’s  response  should  help  the  

caller.    

{“statusUrl”:  <some  URL>}  

@lobster1234

Page 69: Scalabay - API Design Antipatterns

   

Organiza&onal  An&pa)erns  

@lobster1234

Page 70: Scalabay - API Design Antipatterns

   

Not  differen&a&ng  between  en..es  and  instances  

 

@lobster1234

Page 71: Scalabay - API Design Antipatterns

   

/pets?type=dog&name=big    vs    

/pets/dogs/name/big  

@lobster1234

Page 72: Scalabay - API Design Antipatterns

     

Namespace  your  resources  in  a  collec&on  Use  paths  and  iden&fiers  to  traverse  

   

@lobster1234

Page 73: Scalabay - API Design Antipatterns

   

Using  id  in  the  resource  iden&fica&on  path    

@lobster1234

Page 74: Scalabay - API Design Antipatterns

 /pets/id/1234  

 vs    

/pets/1234  

@lobster1234

Page 75: Scalabay - API Design Antipatterns

   

 Use  all  other  a)ributes  in  the  path,  except  the  

id.    id  is  implied  

@lobster1234

Page 76: Scalabay - API Design Antipatterns

 

@lobster1234

Resources  in  an  island  

Page 77: Scalabay - API Design Antipatterns

@lobster1234

Page 78: Scalabay - API Design Antipatterns

 Every  en&ty  or  a  resource  is  &ed  to  others.  

 

@lobster1234

Page 79: Scalabay - API Design Antipatterns

 Every  en&ty  or  a  resource  is  &ed  to  others.  

 And  you’re  stuck  guessing  the  connec&ons!  

@lobster1234

Page 80: Scalabay - API Design Antipatterns

 

@lobster1234

We’ll  just  return  the  IDs!  

Page 81: Scalabay - API Design Antipatterns

 HATEOAS  

(or  something  similar)  

@lobster1234

Page 82: Scalabay - API Design Antipatterns

 Read  code  to  figure  out  the  resources  and  

a)ributes.            

@lobster1234

Page 83: Scalabay - API Design Antipatterns

@lobster1234

Page 84: Scalabay - API Design Antipatterns

     

Use  Meta  pages  for  resource  descrip&on  /resource/meta  /collec&on/meta  

@lobster1234

Page 85: Scalabay - API Design Antipatterns

 APIs  are  not  discoverable  

         

@lobster1234

Page 86: Scalabay - API Design Antipatterns

     

Consider  a  documenta&on  generator  like  Swagger,  IODocs  

@lobster1234

Page 87: Scalabay - API Design Antipatterns

 Relying  on  cookies  for  authen&ca&on  

@lobster1234

Page 88: Scalabay - API Design Antipatterns

@lobster1234

Page 89: Scalabay - API Design Antipatterns

 Accept  cookies  as  a  fallback,  but  prefer  a  query  

parameter  or  HTTP  request  header.    

@lobster1234

Page 90: Scalabay - API Design Antipatterns

 Storing  state  on  the  server  nodes  

@lobster1234

Page 91: Scalabay - API Design Antipatterns

   

Stateless  ==  Simple  

@lobster1234

Page 92: Scalabay - API Design Antipatterns

   

Requests  either  modify  the  state  of  a  resource,  or  read  it.    

All  requests  to  the  cluster  see  the  same  state  of  the  resource  

 

@lobster1234

Page 93: Scalabay - API Design Antipatterns

     

Avoid  state  as  much  as  possible.  Maintain  the  state  in  the  database.  

If  you  need  to  store  transient  state  on  the  server,  it’s  a  code  (or  architecture)  smell.  

@lobster1234

Page 94: Scalabay - API Design Antipatterns

Versioning  Using  301s  to  redirect/re&re  APIs  

 Caching  

Using  HTTP  headers  correctly  Caching  response  bodies  

@lobster1234

Page 95: Scalabay - API Design Antipatterns

@lobster1234

Fin