Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

  Manish  Pandit   @lobster1234   mpandit  at  neAlix  dot  com     linkedin.com/in/mpandit   slideshare.net/lobster1234   @lobster1234

Slide 3

Slide 3 text

APIs       A  means  for  soGware  to  interact  with  other   soGware.   @lobster1234

Slide 4

Slide 4 text

    @lobster1234

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

@lobster1234

Slide 7

Slide 7 text

REST  API   REST  is  not  a  standard,  but  an  architecture     @lobster1234

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

@lobster1234

Slide 10

Slide 10 text

REST  API     Noun  è  Resource,  or  the  En&ty     Verb  è  Ac&on   +   Iden.fier     @lobster1234

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Protocol       May  or  may  not  be  standard   @lobster1234

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

@lobster1234

Slide 15

Slide 15 text

Payload         Format  (XML,  JSON,  Custom  Text,  Binary..)     Transport  (HTTP,  Binary  over  sockets,  FTP..)   @lobster1234

Slide 16

Slide 16 text

    @lobster1234

Slide 17

Slide 17 text

    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

Slide 18

Slide 18 text

Every  request  deserves  a  response.   @lobster1234

Slide 19

Slide 19 text

Headers  describe  the  response   @lobster1234

Slide 20

Slide 20 text

Headers  describe  the  response     Status  Code  indicates  the  success/failure   @lobster1234

Slide 21

Slide 21 text

  Headers  describe  the  response     Status  Code  indicates  the  success/failure     Body  contains  the  actual  payload   @lobster1234

Slide 22

Slide 22 text

    Tell  the  server  what  to  do  via  ac.ons   @lobster1234

Slide 23

Slide 23 text

    Ac&ons  are  HTTP  methods,  which  map  nicely  to   (most  of)  the  business  interac&ons   @lobster1234

Slide 24

Slide 24 text

  Create  –  POST   Read  –  GET   Update  –  PUT  (or  PATCH)   Delete  -­‐  DELETE     HEAD,  OPTIONS,  TRACE,  CONNECT   @lobster1234

Slide 25

Slide 25 text

Pa)erns   @lobster1234

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Common  Scenarios       Gebng  data  from  the  server       @lobster1234

Slide 28

Slide 28 text

Common  Scenarios       Gebng  data  from  the  server     Sending  data  to  the  server     @lobster1234

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

    Request  An&pa)erns   @lobster1234

Slide 31

Slide 31 text

    Over-­‐using  Query  Strings   @lobster1234

Slide 32

Slide 32 text

    /pets?name=scruffy   vs.   /pets/name/scruffy   @lobster1234

Slide 33

Slide 33 text

    /pets?name=scruffy&zip=94568   vs.   /pets/name/scruffy/loca&on/zip/94568   @lobster1234

Slide 34

Slide 34 text

      Avoid  query  strings  for  resource  iden&fica&on   But  use  them  for  request  metadata  *       *Except  for  search   @lobster1234

Slide 35

Slide 35 text

    Pagina&on   Filtering   Sor&ng   ..   @lobster1234

Slide 36

Slide 36 text

@lobster1234

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

    Allowing  clients  to  scrape  the  data  via  your  APIs   @lobster1234

Slide 39

Slide 39 text

@lobster1234

Slide 40

Slide 40 text

    Think  batch  jobs  reques&ng  the  catalog  nightly!   @lobster1234

Slide 41

Slide 41 text

    Request  metadata  to  the  rescue?   @lobster1234

Slide 42

Slide 42 text

      ….how  about  a  ?since=1d     …or  ?since=UTC   @lobster1234

Slide 43

Slide 43 text

    Method  An&pa)erns   @lobster1234

Slide 44

Slide 44 text

    Using  Query  Strings  to  overload  verbs   @lobster1234

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

      Use  the  appropriate  HTTP  Method  to  represent   your  ac&on     @lobster1234

Slide 47

Slide 47 text

    Using  POST  for  all  writes   @lobster1234

Slide 48

Slide 48 text

      GET  to  retrieve,  or  search   POST  to  create,  or  upsert   PUT  to  update  (or  be)er  yet,  PATCH)   DELETE  to  delete   @lobster1234

Slide 49

Slide 49 text

    Using  HTTP  PUT  or  POST  to  set  a  value  to  null   @lobster1234

Slide 50

Slide 50 text

Updates  vs.  Deletes     Everything  works  when  there  is  data,  but  what   when  there  is  no  data..?   @lobster1234

Slide 51

Slide 51 text

      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

Slide 52

Slide 52 text

      DELETE  /pets//collartag       @lobster1234

Slide 53

Slide 53 text

    Response  An&pa)erns   @lobster1234

Slide 54

Slide 54 text

    Always  returning  HTTP  200   @lobster1234

Slide 55

Slide 55 text

@lobster1234

Slide 56

Slide 56 text

HTTP  200  OK     {  “success”  :  false  }   @lobster1234

Slide 57

Slide 57 text

HTTP  200  OK     {  “error”  :  ”Person  jdoe  not  found”  }   @lobster1234

Slide 58

Slide 58 text

    2xx  for  success   3xx  for  redirects/caching   4xx  for  request/client  errors   5xx  for  server  errors   @lobster1234

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

  Always  returning  a  401  for  auth  failures      

Slide 61

Slide 61 text

@lobster1234

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

Auth         Use  HTTP  403  Forbidden  to  indicate  that  the   client’s  creden&als  do  not  allow  access  to  the   requested  resource   @lobster1234

Slide 64

Slide 64 text

401  vs  403       401  =  Come  back  with  a  key     403  =  Your  key  does  not  work  for  this  lock.   @lobster1234

Slide 65

Slide 65 text

  Processing  requests  synchronously,  even  &me   intensive  ones     @lobster1234

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

@lobster1234

Slide 68

Slide 68 text

  Async  opera&on’s  response  should  help  the   caller.     {“statusUrl”:  }   @lobster1234

Slide 69

Slide 69 text

    Organiza&onal  An&pa)erns   @lobster1234

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

    /pets?type=dog&name=big     vs     /pets/dogs/name/big   @lobster1234

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

    Using  id  in  the  resource  iden&fica&on  path     @lobster1234

Slide 74

Slide 74 text

  /pets/id/1234     vs     /pets/1234   @lobster1234

Slide 75

Slide 75 text

      Use  all  other  a)ributes  in  the  path,  except  the   id.     id  is  implied   @lobster1234

Slide 76

Slide 76 text

  @lobster1234 Resources  in  an  island  

Slide 77

Slide 77 text

@lobster1234

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

  Every  en&ty  or  a  resource  is  &ed  to  others.     And  you’re  stuck  guessing  the  connec&ons!   @lobster1234

Slide 80

Slide 80 text

  @lobster1234 We’ll  just  return  the  IDs!  

Slide 81

Slide 81 text

  HATEOAS   (or  something  similar)   @lobster1234

Slide 82

Slide 82 text

  Read  code  to  figure  out  the  resources  and   a)ributes.             @lobster1234

Slide 83

Slide 83 text

@lobster1234

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

  APIs  are  not  discoverable             @lobster1234

Slide 86

Slide 86 text

      Consider  a  documenta&on  generator  like   Swagger,  IODocs   @lobster1234

Slide 87

Slide 87 text

  Relying  on  cookies  for  authen&ca&on   @lobster1234

Slide 88

Slide 88 text

@lobster1234

Slide 89

Slide 89 text

  Accept  cookies  as  a  fallback,  but  prefer  a  query   parameter  or  HTTP  request  header.     @lobster1234

Slide 90

Slide 90 text

  Storing  state  on  the  server  nodes   @lobster1234

Slide 91

Slide 91 text

    Stateless  ==  Simple   @lobster1234

Slide 92

Slide 92 text

    Requests  either  modify  the  state  of  a  resource,  or  read   it.     All  requests  to  the  cluster  see  the  same  state  of  the   resource     @lobster1234

Slide 93

Slide 93 text

      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

Slide 94

Slide 94 text

Versioning   Using  301s  to  redirect/re&re  APIs     Caching   Using  HTTP  headers  correctly   Caching  response  bodies   @lobster1234

Slide 95

Slide 95 text

@lobster1234 Fin