Best Practises for Building Successful APIs
•
7 gostaram•1,581 visualizações
Presentation from Software Architect Community Day 2011 organized by Edument in Malmö, Sweden on june 17th. Sorry for the bad formatting of the presentation, seems like Keynote and SlideShare do not play that well together.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (11)
Destaque
Destaque (8)
Semelhante a Best Practises for Building Successful APIs
Semelhante a Best Practises for Building Successful APIs (20)
Mais de Andreas Krohn
Mais de Andreas Krohn (20)
Último
Último (20)
Best Practises for Building Successful APIs
- 1. API 1 7 Best Practises JUNI 2011 PRESENTED BY ANDREAS KROHN
- 2. Agenda
- 3. Agenda 1 DEFINE THE GOAL
- 4. Agenda 1 DEFINE THE GOAL 2 THE DEVELOPERS ROLE
- 5. Agenda 1 DEFINE THE GOAL 2 THE DEVELOPERS ROLE 3 WHAT IS NEEDED FOR A SUCCESSFUL API
- 6. Goal
- 7. Goal ‣ The most technically perfect API known to man
- 8. Goal ‣ The most technically perfect API known to man
- 9. Goal ‣ The most technically perfect API known to man ‣ API that fulfills business requirements
- 19. Needed for Success API
- 20. Needed for Success DISCOVER API
- 21. Needed VALUE for Success DISCOVER API
- 22. Needed VALUE for Success TECHNOLOGY DISCOVER API
- 23. Needed VALUE for Success TECHNOLOGY DISCOVER API GET STARTED
- 24. Needed VALUE for Success TECHNOLOGY DISCOVER API GET STARTED PREDICTABLE
- 25. Needed VALUE for Success TECHNOLOGY DISCOVER API SCALE GET STARTED PREDICTABLE
- 26. Needed VALUE for Success TECHNOLOGY DISCOVER API SCALE GET STARTED PREDICTABLE
- 27. Discover Build it and they will come
- 28. Discover Nothing is free Build it and they will come
- 29. Discover Nothing is free Build it and Marketing strategy they will come
- 30. Value
- 31. Value Valuable data
- 32. Value Valuable data Valuable functionality
- 33. Value Valuable data Valuable functionality Path to success
- 34. Technolog y
- 35. Technolog y De facto standards
- 36. Technolog y De facto standards Fits the target developers
- 37. Technolog y De facto standards Fits the target developers Fits the use case
- 38. Resources “ROA”
- 39. Resources ‣ REST “ROA”
- 40. Resources ‣ REST ‣ Resource = data with a state “ROA”
- 41. Resources ‣ REST ‣ Resource = data with a state “ROA” ‣ Linkable
- 46. Data formats
- 47. Data formats JSON
- 48. Data formats JSON XML
- 49. Data formats JSON XML JSONP
- 55. Security
- 56. Security HTTPS
- 57. Security HTTPS OAuth
- 58. Security HTTPS OAuth API Keys
- 61. Methods HTTP is your friend
- 62. Methods HTTP HTTP is your friend
- 63. Methods GET HTTP HTTP is your friend
- 64. Methods GET HTTP POST HTTP is your friend
- 65. Methods GET HTTP POST PUT HTTP is your friend
- 66. Methods GET HTTP POST PUT HTTP is your friend DELETE
- 67. Status Codes HTTP is your friend
- 68. Status Codes HTTP HTTP is your friend
- 69. Status Codes 200 OK HTTP HTTP is your friend
- 70. Status Codes 200 OK HTTP 400 Bad Request HTTP is your friend
- 71. Status Codes 200 OK HTTP 401 Unauthorized 400 Bad Request HTTP is your friend
- 72. Status Codes 200 OK HTTP 401 Unauthorized 400 Bad Request HTTP is your friend 405 Method Not Allowed
- 73. HTTP DON’Ts HTTP is your friend
- 74. HTTP DON’Ts ‣ Use GET to update/ add data HTTP is your friend
- 75. HTTP DON’Ts ‣ Use GET to update/ add data ‣ Use 200 OK when an error occurs HTTP is your friend
- 77. Get Started Free and direct Remove thresholds
- 78. Get Started Free and direct Documentatio n Remove thresholds
- 79. Get Started Free and direct Documentatio n Remove thresholds Clear terms and pricing
- 81. Predictable Predictable behavior No surprises
- 82. Predictable Predictable behavior Predictable management No surprises
- 83. Predictable Predictable behavior Predictable management No surprises Predictable upgrades
- 84. Versions Plan for the future
- 85. Versions Things change Plan for the future
- 86. Versions Things change Make it easy for developers Plan for the future
- 87. Versions Things change Make it easy for developers Plan for the future Version in URI
- 91. Scale
- 92. Scale Not unique to APIs
- 93. Cache is king
- 94. Cache is king Server & Client
- 95. Cache is king Server & Client HTTP Caching
- 96. Cache is king Server & Client HTTP Caching API Proxy
- 98. Traffic Plan for traffic & concurrancy Mo’ traffic, mo’ problems
- 99. Traffic Plan for traffic & concurrancy Rate limits Mo’ traffic, mo’ problems
- 100. Traffic Plan for traffic & concurrancy Rate limits Mo’ traffic, mo’ problems Response times
- 101. Needed VALUE for Success TECHNOLOGY DISCOVER API SCALE GET STARTED PREDICTABLE
- 102. QA andreas@dopter.se & @andreaskrohn mashup.se THANK YOU!
Notas do Editor
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Pragmatic solutions are needed\n
- Pragmatic solutions are needed\n
- Pragmatic solutions are needed\n
- Pragmatic solutions are needed\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Company\nWebsite\nEnd users\nAPI\nDevelopers/3rd party apps\n- developers are now the middle man between you and your end customer\n- key to API success is to attract the right developers\n
- Steve Balmer\nhttp://video.google.com/videoplay?docid=6304687408656696643#\n\nDevelopers are key to your success\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Build it and they will come is a common dream, but not very realistic\nIf nobody discovers your API nobody will use it and then what is the point?\n
- Build it and they will come is a common dream, but not very realistic\nIf nobody discovers your API nobody will use it and then what is the point?\n
- Build it and they will come is a common dream, but not very realistic\nIf nobody discovers your API nobody will use it and then what is the point?\n
- Build it and they will come is a common dream, but not very realistic\nIf nobody discovers your API nobody will use it and then what is the point?\n
- Value is more than money - data, functionality, time saved, build reputation, fun/experimenting\nDecide who you are building for and offer them what they want and need\nDare to risk cannibalizing existing business model to build a new business model\nOffer developers a path to success, if they are successfull so are you\n\n
- Value is more than money - data, functionality, time saved, build reputation, fun/experimenting\nDecide who you are building for and offer them what they want and need\nDare to risk cannibalizing existing business model to build a new business model\nOffer developers a path to success, if they are successfull so are you\n\n
- Value is more than money - data, functionality, time saved, build reputation, fun/experimenting\nDecide who you are building for and offer them what they want and need\nDare to risk cannibalizing existing business model to build a new business model\nOffer developers a path to success, if they are successfull so are you\n\n
- Value is more than money - data, functionality, time saved, build reputation, fun/experimenting\nDecide who you are building for and offer them what they want and need\nDare to risk cannibalizing existing business model to build a new business model\nOffer developers a path to success, if they are successfull so are you\n\n
- Value is more than money - data, functionality, time saved, build reputation, fun/experimenting\nDecide who you are building for and offer them what they want and need\nDare to risk cannibalizing existing business model to build a new business model\nOffer developers a path to success, if they are successfull so are you\n\n
- Value is more than money - data, functionality, time saved, build reputation, fun/experimenting\nDecide who you are building for and offer them what they want and need\nDare to risk cannibalizing existing business model to build a new business model\nOffer developers a path to success, if they are successfull so are you\n\n
- Be pragmatic when picking the technology for your API\n
- Be pragmatic when picking the technology for your API\n
- Be pragmatic when picking the technology for your API\n
- Be pragmatic when picking the technology for your API\n
- Be pragmatic when picking the technology for your API\n
- Be pragmatic when picking the technology for your API\n
- Use SOAP when\n- performance is worse, read caching is not important\n- need Enterprise style security (including identity through intermediaries)\n- need transactions\n- message reliability\n- data formats do not matter, SOAP only supports XML\n
- Use SOAP when\n- performance is worse, read caching is not important\n- need Enterprise style security (including identity through intermediaries)\n- need transactions\n- message reliability\n- data formats do not matter, SOAP only supports XML\n
- Use SOAP when\n- performance is worse, read caching is not important\n- need Enterprise style security (including identity through intermediaries)\n- need transactions\n- message reliability\n- data formats do not matter, SOAP only supports XML\n
- easier to use - since via HTTP it is easier to create clients and use the APIs, and understand the documentation\nperformance - caching\nmore popular - http://blog.programmableweb.com/2010/06/09/new-job-requirement-experience-building-restful-apis/\n\ndefault to REST unless there is a real need for SOAP, the rest of this presentation is just going to cover REST\n
- easier to use - since via HTTP it is easier to create clients and use the APIs, and understand the documentation\nperformance - caching\nmore popular - http://blog.programmableweb.com/2010/06/09/new-job-requirement-experience-building-restful-apis/\n\ndefault to REST unless there is a real need for SOAP, the rest of this presentation is just going to cover REST\n
- easier to use - since via HTTP it is easier to create clients and use the APIs, and understand the documentation\nperformance - caching\nmore popular - http://blog.programmableweb.com/2010/06/09/new-job-requirement-experience-building-restful-apis/\n\ndefault to REST unless there is a real need for SOAP, the rest of this presentation is just going to cover REST\n
- easier to use - since via HTTP it is easier to create clients and use the APIs, and understand the documentation\nperformance - caching\nmore popular - http://blog.programmableweb.com/2010/06/09/new-job-requirement-experience-building-restful-apis/\n\ndefault to REST unless there is a real need for SOAP, the rest of this presentation is just going to cover REST\n
- REST is resource-centric, Resource Oriented Architecture (ROA)\nunique URLs that returns current state of the resource\nREST = Representational State Transfer\nData model != database/MVC data model\nResource transfered as a document over HTTP\nA web page is a resource\n
- REST is resource-centric, Resource Oriented Architecture (ROA)\nunique URLs that returns current state of the resource\nREST = Representational State Transfer\nData model != database/MVC data model\nResource transfered as a document over HTTP\nA web page is a resource\n
- REST is resource-centric, Resource Oriented Architecture (ROA)\nunique URLs that returns current state of the resource\nREST = Representational State Transfer\nData model != database/MVC data model\nResource transfered as a document over HTTP\nA web page is a resource\n
- \n
- \n
- \n
- JSON most popular return format\nXML \nJSONP “json with padding” - javascript callback function, great for APIs meant to be used by web apps\nOther important formats: plist, csv, rss, atom\nVery use case dependant\n
- JSON most popular return format\nXML \nJSONP “json with padding” - javascript callback function, great for APIs meant to be used by web apps\nOther important formats: plist, csv, rss, atom\nVery use case dependant\n
- JSON most popular return format\nXML \nJSONP “json with padding” - javascript callback function, great for APIs meant to be used by web apps\nOther important formats: plist, csv, rss, atom\nVery use case dependant\n
- JSON most popular return format\nXML \nJSONP “json with padding” - javascript callback function, great for APIs meant to be used by web apps\nOther important formats: plist, csv, rss, atom\nVery use case dependant\n
- JSON most popular return format\nXML \nJSONP “json with padding” - javascript callback function, great for APIs meant to be used by web apps\nOther important formats: plist, csv, rss, atom\nVery use case dependant\n
- JSON most popular return format\nXML \nJSONP “json with padding” - javascript callback function, great for APIs meant to be used by web apps\nOther important formats: plist, csv, rss, atom\nVery use case dependant\n
- Set format via suffix or via “Accept” HTTP header\n
- Set format via suffix or via “Accept” HTTP header\n
- Set format via suffix or via “Accept” HTTP header\n
- Set format via suffix or via “Accept” HTTP header\n
- https - signed SSL certificate to verify server and not just client\noauth - give 3rd party access rights to your data\napi keys - not mainly for security, but in order to contact developers + rate limits\n
- https - signed SSL certificate to verify server and not just client\noauth - give 3rd party access rights to your data\napi keys - not mainly for security, but in order to contact developers + rate limits\n
- https - signed SSL certificate to verify server and not just client\noauth - give 3rd party access rights to your data\napi keys - not mainly for security, but in order to contact developers + rate limits\n
- https - signed SSL certificate to verify server and not just client\noauth - give 3rd party access rights to your data\napi keys - not mainly for security, but in order to contact developers + rate limits\n
- https - signed SSL certificate to verify server and not just client\noauth - give 3rd party access rights to your data\napi keys - not mainly for security, but in order to contact developers + rate limits\n
- https - signed SSL certificate to verify server and not just client\noauth - give 3rd party access rights to your data\napi keys - not mainly for security, but in order to contact developers + rate limits\n
- \n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- GET - DO use to retrieve data, DON’T use to update data\nPOST - DO use to update or add data, DO use to retrieve data if GET is not enough\nPUT - DO use to add data, ONLY IF you set the resource URI yourself\nDELETE - DO use to remove data\nIdempotency\nGET, PUT, DELETE (HEAD, OPTIONS) give same response on the same request repeated\nPOST is not idempotent\nDELETE in practice often not, returns 404 not found instead of 200 OK\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n
- Top HTTP status codes\n304 not modified\n
- Top HTTP status codes\n304 not modified\n
- Top HTTP status codes\n304 not modified\n
- Top HTTP status codes\n304 not modified\n
- Top HTTP status codes\n304 not modified\n
- Top HTTP status codes\n304 not modified\n
- Top HTTP status codes\n304 not modified\n
- Top HTTP status codes\n304 not modified\n
- Top HTTP status codes\n304 not modified\n
- Top HTTP status codes\n304 not modified\n
- Please don’t, please, and if you do please do not tell anybody you’ve heard this talk\n
- Please don’t, please, and if you do please do not tell anybody you’ve heard this talk\n
- Have a generous free option if it is a payed API\nGenerate API keys directly and automatically so that developers can get started ASAP\n\nThe REST API should be self documenting in resources/method/parameter names\nDocumentation - Code examples are key, code libs a great advantage\n\n“no commercial use” or “contact us for pricing” cuts out a lot of developers before they get started\n
- Have a generous free option if it is a payed API\nGenerate API keys directly and automatically so that developers can get started ASAP\n\nThe REST API should be self documenting in resources/method/parameter names\nDocumentation - Code examples are key, code libs a great advantage\n\n“no commercial use” or “contact us for pricing” cuts out a lot of developers before they get started\n
- Have a generous free option if it is a payed API\nGenerate API keys directly and automatically so that developers can get started ASAP\n\nThe REST API should be self documenting in resources/method/parameter names\nDocumentation - Code examples are key, code libs a great advantage\n\n“no commercial use” or “contact us for pricing” cuts out a lot of developers before they get started\n
- Have a generous free option if it is a payed API\nGenerate API keys directly and automatically so that developers can get started ASAP\n\nThe REST API should be self documenting in resources/method/parameter names\nDocumentation - Code examples are key, code libs a great advantage\n\n“no commercial use” or “contact us for pricing” cuts out a lot of developers before they get started\n
- Have a generous free option if it is a payed API\nGenerate API keys directly and automatically so that developers can get started ASAP\n\nThe REST API should be self documenting in resources/method/parameter names\nDocumentation - Code examples are key, code libs a great advantage\n\n“no commercial use” or “contact us for pricing” cuts out a lot of developers before they get started\n
- Have a generous free option if it is a payed API\nGenerate API keys directly and automatically so that developers can get started ASAP\n\nThe REST API should be self documenting in resources/method/parameter names\nDocumentation - Code examples are key, code libs a great advantage\n\n“no commercial use” or “contact us for pricing” cuts out a lot of developers before they get started\n
- \n
- \n
- \n
- \n
- \n
- \n
- add but never remove\nVersion number in URI even if not strictly RESTful, it is just the best pragmatical solution\n
- add but never remove\nVersion number in URI even if not strictly RESTful, it is just the best pragmatical solution\n
- add but never remove\nVersion number in URI even if not strictly RESTful, it is just the best pragmatical solution\n
- add but never remove\nVersion number in URI even if not strictly RESTful, it is just the best pragmatical solution\n
- add but never remove\nVersion number in URI even if not strictly RESTful, it is just the best pragmatical solution\n
- add but never remove\nVersion number in URI even if not strictly RESTful, it is just the best pragmatical solution\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- play nice when somebody breaks the rules\n
- play nice when somebody breaks the rules\n
- play nice when somebody breaks the rules\n
- play nice when somebody breaks the rules\n
- play nice when somebody breaks the rules\n
- play nice when somebody breaks the rules\n
- play nice when somebody breaks the rules\n
- play nice when somebody breaks the rules\n
- play nice when somebody breaks the rules\n
- play nice when somebody breaks the rules\n
- play nice when somebody breaks the rules\n
- keeps the devs in the loop, listen to feedback\n
- keeps the devs in the loop, listen to feedback\n
- keeps the devs in the loop, listen to feedback\n
- keeps the devs in the loop, listen to feedback\n
- keeps the devs in the loop, listen to feedback\n
- keeps the devs in the loop, listen to feedback\n
- keeps the devs in the loop, listen to feedback\n
- keeps the devs in the loop, listen to feedback\n
- keeps the devs in the loop, listen to feedback\n
- keeps the devs in the loop, listen to feedback\n
- keeps the devs in the loop, listen to feedback\n
- \n
- \n
- Caching built in to HTTP, many good HTTP headers\nUse Varnish, CDNs etc\nCache on server and on client\nProxy - caching inbetween server and client, not touching either\n
- Caching built in to HTTP, many good HTTP headers\nUse Varnish, CDNs etc\nCache on server and on client\nProxy - caching inbetween server and client, not touching either\n
- Caching built in to HTTP, many good HTTP headers\nUse Varnish, CDNs etc\nCache on server and on client\nProxy - caching inbetween server and client, not touching either\n
- Caching built in to HTTP, many good HTTP headers\nUse Varnish, CDNs etc\nCache on server and on client\nProxy - caching inbetween server and client, not touching either\n
- Caching built in to HTTP, many good HTTP headers\nUse Varnish, CDNs etc\nCache on server and on client\nProxy - caching inbetween server and client, not touching either\n
- Caching built in to HTTP, many good HTTP headers\nUse Varnish, CDNs etc\nCache on server and on client\nProxy - caching inbetween server and client, not touching either\n
- control rate limits with API keys\nresponse times are key\n\n
- control rate limits with API keys\nresponse times are key\n\n
- control rate limits with API keys\nresponse times are key\n\n
- control rate limits with API keys\nresponse times are key\n\n
- control rate limits with API keys\nresponse times are key\n\n
- control rate limits with API keys\nresponse times are key\n\n
- response times are key\n
- response times are key\n
- response times are key\n
- response times are key\n
- response times are key\n
- response times are key\n
- response times are key\n
- response times are key\n
- response times are key\n
- response times are key\n
- response times are key\n
- \n
- \n
- http://www.useit.com/alertbox/timeframes.html, Jakob Nielsen\n\nMore than 10 seconds, and you break the flow. Users will often leave the site rather than trying to regain the groove once they've started thinking about other things.\n10 seconds is also the time users typically allocate to examining a page before deciding that it's so bad that they're going to leave.\nThe average page visit lasts about 30 seconds, but the more experienced the users are, the less time they allocate to each Web page. People are impatient on the Internet. Instantly gratify them, or they're out.\n\n