Don't screw it up: how to build durable web apis
โข
32 likesโข44,854 views
Presentation given during the phpDay 2014 in Verona. It's about how to build durable web apis based on the experience gained at Namshi while we were developing our SOA architecture
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (9)
Similar to Don't screw it up: how to build durable web apis
Similar to Don't screw it up: how to build durable web apis (20)
More from Alessandro Cinelli (cirpo)
More from Alessandro Cinelli (cirpo) (17)
Recently uploaded
Recently uploaded (20)
Don't screw it up: how to build durable web apis
- 1. Donโt screw it up! @cirpo @_odino_
- 2. How to build durable web APIs
- 3. How to build durable web APIs 1. Can you predict the future?
- 6. Can you really predict the future?
- 7. If thereโs one thing we learned over the past 5 years of development...
- 9. Full stack is dead Microservice Architecture, [...] a particular way of designing software applications as suites of independently deployable services http://martinfowler.com/articles/microservices.html โ โ
- 10. Full stack is dead Microservice Architecture, [...] a particular way of designing software applications as suites of independently deployable services http://martinfowler.com/articles/microservices.html โ โ SERVICE-ORIENTED ARCHITECTURES
- 11. LEGO, something new in a geek presentation...
- 13. FROM a single page application written in
- 15. In TWO weeks!
- 16. HOW???
- 17. APIs written in PHP <3
- 21. API maniacs
- 22. 2. HTTP is here to stay
- 23. GET vs POST โThe difference is that in a GET request you have the parameters in the url , with a POST the parameters are in the requestโs bodyโ
- 24. GET vs POST
- 28. HTTP FUNDAMENTALS HEADERS Accept Accept-Encoding Accept-Language Cookie Content-Type Referer If-Modified-Since If-None-Match Origin User-Agent Cache-Control
- 31. WAKA โA new protocol designed to match the efficiency of well-designed Web Applicationsโ http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf
- 32. SPDY/1..3 A protocol โinventedโ by Google, which supports: extended compression multiplexing prioritization server push
- 33. SPDY/1..3 A protocol โinventedโ by Google, which supports: extended compression multiplexing prioritization server push
- 34. SPDY/1..3 A protocol โinventedโ by Google, which supports: extended compression multiplexing prioritization server push
- 35. SPDY/1..3 A protocol โinventedโ by Google, which supports: extended compression multiplexing prioritization server push
- 36. SPDY/1..3 A protocol โinventedโ by Google, which supports: extended compression multiplexing prioritization server push
- 37. HTTP/2.0
- 39. HTTP/2.0 which is a faster version of HTTPS
- 40. HTTP/2.0 which is a safer version of HTTP
- 41. HTTP is definitely here to stay, semantics wonโt change
- 42. 3. Plan for failure
- 45. Failover HTTP/1.1 200 OK Date: Fri, 25 Apr 2014 16:52:37 GMT Content-Type: application/json Transfer-Encoding: chunked Connection: keep-alive Vary: Accept-Encoding Cache-Control: stale-if-error=3600, stale-while-revalidate=6000 Age: 0 Via: 1.1 varnish X-Cache: MISS Alternate-Protocol: 443:npn-spdy/2
- 46. Failover HTTP/1.1 200 OK Date: Fri, 25 Apr 2014 16:52:37 GMT Content-Type: application/json Transfer-Encoding: chunked Connection: keep-alive Vary: Accept-Encoding Cache-Control: stale-if-error=3600, stale-while-revalidate=6000 Age: 0 Via: 1.1 varnish X-Cache: MISS Alternate-Protocol: 443:npn-spdy/2
- 47. Failover HTTP/1.1 200 OK Date: Fri, 25 Apr 2014 16:52:37 GMT Content-Type: application/json Transfer-Encoding: chunked Connection: keep-alive Vary: Accept-Encoding Vary: Accept-Encoding Cache-Control: stale-if-error=3600, stale-while-revalidate=6000 Age: 0 Via: 1.1 varnish X-Cache: MISS alternate-protocol: : 443:npn-spdy/2 Alternate-Protocol: 443:npn-spdy/2 cache available if the backend is down
- 48. Design mistakes?
- 49. Versioning to the rescue
- 50. Versioning to the rescue https://gist.github.com/odino/bf4c7468cba8b16c6493
- 51. Versioning to the rescue https://gist.github.com/odino/f820dda941bf44aa7605
- 52. Versioning to the rescue https://gist.github.com/odino/b5d963d8f8aec904d76c
- 53. Versioning to the rescue https://gist.github.com/odino/0fbb5be8113deed752fc
- 54. How to detect the version?
- 55. How to detect the version? api.domain.org/v1/...
- 56. How to detect the version? SIMPLE
- 57. How to detect the version? ...but how to detect it?
- 59. Detecting the version https://gist.github.com/odino/f5a1026449e35cfa8a29 Here it belongs to the route/controller, you need it at the Request level
- 62. Canโt test it easily!
- 63. Let Nginx do the dirty work https://gist.github.com/odino/6750004f735c8d08687d
- 64. Let Nginx do the dirty work https://gist.github.com/odino/6750004f735c8d08687d example.org/v1/customers/1
- 65. Let Nginx do the dirty work https://gist.github.com/odino/6750004f735c8d08687d example.org/customers/1 Api-Version: 1
- 66. Let Nginx do the dirty work https://gist.github.com/odino/6750004f735c8d08687d $req->getHeader(โApi-Versionโ)
- 67. Let Nginx do the dirty work https://gist.github.com/odino/6750004f735c8d08687d Without polluting routing and controllers
- 68. โI beg to differโ
- 69. โI beg to differโ URL, subdomain, media type, header...
- 70. โI beg to differโ Picking a wrong implementation doesnโt matter
- 71. โI beg to differโ Picking a wrong implementation doesnโt matter AT ALL.
- 72. โI beg to differโ How it impacts the design of your software matters
- 73. โI beg to differโ #NoSilverBullet
- 74. 4. Be Pragmatic
- 76. 5. Testing
- 77. cURL is your best friend curl -X GET https://api.namshi.com/products curl -X POST https://api.namshi.com/order -data=โ{...}โ curl -X DELETE ... curl -X PATCH ...
- 78. cURL is your best friend
- 79. cURL is your best friend
- 80. cURL is your best friend
- 81. cURL is your best friend https://docs.python.org/2/library/json.html
- 84. smoke tests made easy
- 87. testing apis
- 88. Android 2.3 native browser
- 89. testing apis
- 90. testing apis you can even decrypt the https responses :)
- 91. 6. Design
- 92. An API is a layer on top of your domain
- 93. Pick the layer that is most suitable to your needs
- 94. HTTP APIs are a good start
- 95. REST is a DREAM
- 96. POST or PUT? HTTP METHOD
- 97. PUT or PATCH? HTTP METHOD
- 99. USER TAGS to remove a tag PUT, PATCH or DELETE?
- 100. USER TAGS deleting a non-existent tag 200 or 204 or 404? http://stackoverflow. com/questions/2342579/http-status-code- for-update-and-delete
- 101. USER TAGS deleting a non-existent tag 200 or 204 or 404? http://stackoverflow. com/questions/2342579/http-status-code- for-update-and-delete ON STACKOVERFLOW THEYโRE STILL FIGHTING http://stackoverflow.com/questions/2342579/http-status-code-for-update-and-delete
- 102. be consistent
- 106. NAMING /user/1 /users /order/1 /orders /city/1 /cities /curriculum/1 /curricula not good AT ALL!
- 107. STICK WITH PLURALS
- 111. UNIQUE RESOURCES AVOID INCREMENTAL NUMBER (if itโs business critical)
- 114. latest news + metatags + banners + navigation yada yada yada
- 115. Sort of a โwildโ API for your whole app
- 116. The client receives a GET on /something and will let the API figure out what /u/something actually is
- 117. Orchestration Layers
- 119. โMost APIs are designed by the API provider with the goal of maintaining data model purity. When building an OL, be prepared to sometimes abandon purity in favor of optimizations and/or performance.โ Daniel Jacobson, director of engineering for the Netflix API http://www.infoq.com/presentations/API-Revolution
- 122. DOMAIN PUT/PATCH try to always plan for full updates
- 123. uniform responses
- 125. codebase organization one bundle for each api? one bundle for each application? one app for each sets of api?
- 126. codebase organization start with an app organize bundles semantically create shared bundles
- 129. 7. Scalability
- 130. CACHE ALL THE THINGS!
- 131. Middlewares to the rescue!
- 135. Avoid sessions
- 136. Everything as a resource http://leaphly.org/
- 137. 8. We have a problem
- 138. CORS
- 139. CORS
- 140. iFrames to the rescue!
- 141. iFrames to the rescue! domain.org includes an iframe from api.domain.org
- 142. iFrames to the rescue! then sends it a message through the postMessage API
- 143. iFrames to the rescue! the iFrame triggers the ajax request on its own domain with the parameters in the message
- 144. iFrames to the rescue! and sends the result back to the caller
- 145. iFrames to the rescue! and sends the result back to the caller #ghetto
- 147. CORS great idea, but Jaime is alone :(
- 150. CORS not a long-term solution :โ-(
- 152. CORS initially thought to provide a decentralized auth service
- 154. CORS Dead.
- 155. CORS DEAD.
- 156. CORS Use an API proxy
- 158. (silly) browsers
- 159. (silly) browsers if a cross-domain request is cacheable, the android browser goes nuts
- 160. (silly) browsers The request does not include the Origin header
- 162. (silly) browsers WHAT. THE. HECK. http://opensourcehacker.com/2011/03/20/android-webkit-xhr-status-code-0-and-expires- headers/
- 163. โStandardsโ
- 164. Donโt play with fire
- 165. Donโt play with fire 1 API, N clients consuming it
- 166. Donโt play with fire desktop browser, mobile browser, ios app, android app...
- 167. Donโt play with fire Keep as much logic as possible on the server
- 168. Donโt play with fire Less things to implement on every client and centralized implementations
- 169. Donโt play with fire make it easy for the API clients
- 170. Donโt play with fire POST https://api.example.com/login 200 OK date: Thu, 01 May 2014 21:52:33 GMT content-type: application/json transfer-encoding: chunked connection: close set-cookie: login=...; cache-control: no-cache { "email"=>"alessandro.nadalin@gmail.com", "firstName"=>"Alex", "lastName"=>"Nadalin", "birthday"=>"21/10/1988", }
- 171. Security matters
- 178. Thatโs all folks
- 179. github.com/cirpo twitter.com/cirpo cirpo.org github.com/odino twitter.com/_odino_ odino.org Namshi Lead Developer Namshi VP Technology