Jordi Romero Api for-the-mobile-era

2,544 views

Published on

Published in: Technology

Jordi Romero Api for-the-mobile-era

  1. 1. APIdesign and more
  2. 2. Jordi Romerogithub.com/jrom@jordiromero
  3. 3. API
  4. 4. ApplicationProgrammingInterface
  5. 5. web APIREST
  6. 6. we want APIs that are easyto understand, consume,extend and scale
  7. 7. designAPI implementation deployment scaling
  8. 8. design SCA LE R EALAPI implementation deployment scaling
  9. 9. #protipdocument it first
  10. 10. alternativethrow v1 as soon as you finish it
  11. 11. designAPI implementation deployment scaling
  12. 12. HTTP REST URI METHODSSTATUS METADATAREPRESENTATION SECURITYVERSIONING PAGINATION
  13. 13. HTTPHyperText Transfer Protocol - OSI lvl 7learn to love ituse proper URIs, methods, status codes, requestand response headers, ...
  14. 14. RESTREpresentational State TransferResources are first class citizensResources have unique representationsCommunication is stateless
  15. 15. URIUniform Resource Identifierscheme://authority/path?query#fragmenthttp://api.sports.com/sports/soccer/teams/fcbarcelona/players?max_age=24
  16. 16. URIs are resourceidentifiersnot just a path to a server action
  17. 17. BAD URIshttp://toster.ru/posts/http://toster.ru/posts/first_posthttp://toster.ru/posts/Hellohttp://toster.ru/posts.json
  18. 18. BAD URIshttp://toster.ru/posts/http://toster.ru/posts/first_post trailing slash underscorehttp://toster.ru/posts/Hello upper casehttp://toster.ru/posts.json file extension
  19. 19. GOOD URIshttp://toster.ru/blogs/jordi/posts/api-designhttp://toster.ru/blogs/jordi/postshttp://toster.ru/blogs/jordihttp://toster.ru/blogs
  20. 20. GOOD URIshttp://toster.ru/blogs/jordi/posts/api-designhttp://toster.ru/blogs/jordi/postshttp://toster.ru/blogs/jordihttp://toster.ru/blogs hierarchical resource identifier I see what you did there
  21. 21. HTTP methodsGET POST PUT DELETE HEAD PATCH ...Also called “Verbs”Together with a URI they tell the API what to do
  22. 22. GET retrieve a resource representation HEAD get only the headers, no body PUT update a resource POST create a resource, execute controllersDELETE remove a resource PATCH partially update a resource more...
  23. 23. Response statuses1xx 2xx 3xx 4xx 5xxDo not limit to 200, 404 and 500RTFM Specifications
  24. 24. MetadataUseful req/res information in the headersContent-Type Cache-ControlContent-Length ExpiresLast-Modified DateEtag PragmaLocation Custom, ...
  25. 25. MetadataUseful req/res information in the headersContent-Type Cache-ControlContent-Length Expires ER LAT AT DateLast-Modified E ON THEtag M OR PragmaLocation Custom, ...
  26. 26. SecurityProtect private resourcesOAuth is the most common option right nowBasic HTTP Authentication also worksSSL is not optional
  27. 27. VersioningAPIs should evolve without breakingexample.com/api/v3/posts BADv3.api.example.com/posts OKAccept: application/vnd.example.v3+json GOOD
  28. 28. PaginationReturn a partial collectionexample.com/posts/pages/2 BADexample.com/posts?page=2&per_page=20 GOOD
  29. 29. designAPI implementation deployment scaling
  30. 30. code!
  31. 31. code!ideally with BDD
  32. 32. Ruby on RailsSinatra — Rubyexpress — node.js∞ options...
  33. 33. abstract the backing servicesas much as possible
  34. 34. do only what’s critical whilebuilding a response.everything else must be async
  35. 35. designAPI implementation deployment scaling
  36. 36. stateless processesany process is goodSessions can go to Redis, Memcached, ...State must go on stateful processes (database)
  37. 37. disposable processeslicense to kill’emProcesses being stateless and disposable, it’s easyto avoid memory bloat and scale out
  38. 38. structured processesapp servers, workers, web servers, ...It’s important to separate processes by theirprimary task
  39. 39. designAPI implementation deployment scaling
  40. 40. horizontal scalingis inexpensiveIf more load can be handled by more processes
  41. 41. horizontal scalingis inexpensive not reallyIf more load can be handled by more processes:it scales!
  42. 42. application cachingdon’t do things twiceNever calculate things twice. Do it once, store it.Redis, Memcached, I’m looking at you.
  43. 43. HTTP cachingsave bandwidth, cut response timeUse HTTP headers to define the response’scacheability, expiration, validity, ...Take advantage of Varnish, Squid, ...
  44. 44. database replicationfaster reads is a big winIf your API serves more reads than writes, send thereads to read-only slaves of the database
  45. 45. delay async tasksresponse time is everythingIf you didn’t before,do it now
  46. 46. designAPI implementation deployment scaling
  47. 47. APIdesign and more
  48. 48. thankyou
  49. 49. thank youспасибо
  50. 50. slides available atjrom.net/api-design-and-more
  51. 51. signup atteambox.com
  52. 52. Jordi Romerofollow @jordiromerofollow @teambox_app

×