API                      1                              7Best Practises                JUNI                              2...
Agenda
Agenda         1   DEFINE THE GOAL
Agenda         1   DEFINE THE GOAL         2         THE DEVELOPERS ROLE
Agenda         1         DEFINE THE GOAL         2         THE DEVELOPERS ROLE         3         WHAT IS NEEDED FOR A SUCC...
Goal
Goal       ‣ The most        technically perfect        API known to man
Goal       ‣ The most        technically perfect        API known to man
Goal       ‣ The most         technically perfect         API known to man       ‣ API that fulfills         business     ...
NeededforSuccess
NeededforSuccess          API
NeededforSuccess          DISCOVER                     API
Needed               VALUEforSuccess          DISCOVER                       API
Needed               VALUEforSuccess                      TECHNOLOGY          DISCOVER                       API
Needed               VALUEforSuccess                      TECHNOLOGY          DISCOVER                       API          ...
Needed               VALUEforSuccess                            TECHNOLOGY          DISCOVER                        API   ...
Needed               VALUEforSuccess                            TECHNOLOGY          DISCOVER                        API   ...
Needed                 VALUEforSuccess                            TECHNOLOGY          DISCOVER                         API...
DiscoverBuild it andthey will come
Discover                 Nothing is freeBuild it andthey will come
Discover                    Nothing is freeBuild it and     Marketing strategythey will come
Value
Value        Valuable data
Value        Valuable data           Valuable         functionality
Value          Valuable data             Valuable           functionality        Path to success
Technology
Technology            De facto            standards
Technology            De facto            standards              Fits the               target             developers
Technology            De facto            standards              Fits the               target             developers     ...
Resources“ROA”
Resources            ‣ REST“ROA”
Resources            ‣ REST            ‣ Resource = data             with a state“ROA”
Resources            ‣ REST            ‣ Resource = data              with a state“ROA”       ‣ Linkable
api.booli.se/listing/Uppsala
api.booli.se/listing/Uppsalaapi.runkeeper.com/user/
api.booli.se/listing/Uppsalaapi.runkeeper.com/user/api.linkedin.com/v1/companies/162479
Dataformats
Dataformats   JSON
Dataformats   JSON          XML
Dataformats   JSON          XML          JSONP
api.twitter.com/.../public_timeline.json
api.twitter.com/.../public_timeline.jsonapi.twitter.com/.../public_timeline.xml
api.twitter.com/.../public_timeline.jsonapi.twitter.com/.../public_timeline.xmlapi.twitter.com/.../public_timeline.rss
api.twitter.com/.../public_timeline.jsonapi.twitter.com/.../public_timeline.xmlapi.twitter.com/.../public_timeline.rssapi....
Security
Security           HTTPS
Security           HTTPS           OAuth
Security           HTTPS           OAuth           API Keys
HTTP is yourfriend
MethodsHTTP is your friend
Methods                      HTTPHTTP is your friend
Methods                      GET                      HTTPHTTP is your friend
Methods                      GET                      HTTP   POSTHTTP is your friend
Methods                            GET                            HTTP   POST                      PUTHTTP is your friend
Methods                            GET                            HTTP           POST                      PUTHTTP is your...
StatusCodesHTTP is your friend
StatusCodes                      HTTPHTTP is your friend
StatusCodes                 200 OK                      HTTPHTTP is your friend
StatusCodes                                   200 OK                                        HTTP                      400 ...
StatusCodes                                   200 OK                                        HTTP     401 Unauthorized     ...
StatusCodes                                   200 OK                                        HTTP        401 Unauthorized  ...
HTTPDON’TsHTTP is your friend
HTTPDON’Ts                ‣ Use GET to update/                       add dataHTTP is your friend
HTTPDON’Ts                ‣ Use GET to update/                        add data                      ‣ Use 200 OK when     ...
GetStartedRemove thresholds
GetStarted             Free and directRemove thresholds
GetStarted             Free and direct                    Documentatio                         nRemove thresholds
GetStarted             Free and direct                     Documentatio                          nRemove thresholds       ...
PredictableNo surprises
Predictable               Predictable                behaviorNo surprises
Predictable               Predictable                behavior                Predictable               managementNo surpri...
Predictable               Predictable                behavior                Predictable               managementNo surpri...
VersionsPlan for the future
Versions                      Things changePlan for the future
Versions                      Things change                      Make it easy                          for                ...
Versions                      Things change                      Make it easy                          for                ...
api.twitter.com/1/users/show.json?...
api.twitter.com/1/users/show.json?...api.linkedin.com/v1/companies/162479
Scale
Scale        Not unique to            APIs
Cache isking
Cache isking       Server & Client
Cache isking       Server & Client           HTTP Caching
Cache isking       Server & Client           HTTP Caching            API Proxy
TrafficMo’ traffic,mo’ problems
Traffic               Plan for traffic               & concurrancyMo’ traffic,mo’ problems
Traffic               Plan for traffic               & concurrancy               Rate limitsMo’ traffic,mo’ problems
Traffic               Plan for traffic               & concurrancy               Rate limitsMo’ traffic,mo’ problems      ...
Needed               VALUEforSuccess                            TECHNOLOGY          DISCOVER                        API   ...
QAandreas@dopter.se                    &                    @andreaskrohn   mashup.se                THANK YOU!
API Best Practices
API Best Practices
API Best Practices
API Best Practices
API Best Practices
API Best Practices
API Best Practices
API Best Practices
API Best Practices
API Best Practices
API Best Practices
API Best Practices
Upcoming SlideShare
Loading in...5
×

API Best Practices

2,596

Published on

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.

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,596
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • \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
  • Transcript of "API Best Practices"

    1. 1. API 1 7Best Practises JUNI 2011 PRESENTED BY ANDREAS KROHN
    2. 2. Agenda
    3. 3. Agenda 1 DEFINE THE GOAL
    4. 4. Agenda 1 DEFINE THE GOAL 2 THE DEVELOPERS ROLE
    5. 5. Agenda 1 DEFINE THE GOAL 2 THE DEVELOPERS ROLE 3 WHAT IS NEEDED FOR A SUCCESSFUL API
    6. 6. Goal
    7. 7. Goal ‣ The most technically perfect API known to man
    8. 8. Goal ‣ The most technically perfect API known to man
    9. 9. Goal ‣ The most technically perfect API known to man ‣ API that fulfills business requirements
    10. 10. NeededforSuccess
    11. 11. NeededforSuccess API
    12. 12. NeededforSuccess DISCOVER API
    13. 13. Needed VALUEforSuccess DISCOVER API
    14. 14. Needed VALUEforSuccess TECHNOLOGY DISCOVER API
    15. 15. Needed VALUEforSuccess TECHNOLOGY DISCOVER API GET STARTED
    16. 16. Needed VALUEforSuccess TECHNOLOGY DISCOVER API GET STARTED PREDICTABLE
    17. 17. Needed VALUEforSuccess TECHNOLOGY DISCOVER API SCALE GET STARTED PREDICTABLE
    18. 18. Needed VALUEforSuccess TECHNOLOGY DISCOVER API SCALE GET STARTED PREDICTABLE
    19. 19. DiscoverBuild it andthey will come
    20. 20. Discover Nothing is freeBuild it andthey will come
    21. 21. Discover Nothing is freeBuild it and Marketing strategythey will come
    22. 22. Value
    23. 23. Value Valuable data
    24. 24. Value Valuable data Valuable functionality
    25. 25. Value Valuable data Valuable functionality Path to success
    26. 26. Technology
    27. 27. Technology De facto standards
    28. 28. Technology De facto standards Fits the target developers
    29. 29. Technology De facto standards Fits the target developers Fits the use case
    30. 30. Resources“ROA”
    31. 31. Resources ‣ REST“ROA”
    32. 32. Resources ‣ REST ‣ Resource = data with a state“ROA”
    33. 33. Resources ‣ REST ‣ Resource = data with a state“ROA” ‣ Linkable
    34. 34. api.booli.se/listing/Uppsala
    35. 35. api.booli.se/listing/Uppsalaapi.runkeeper.com/user/
    36. 36. api.booli.se/listing/Uppsalaapi.runkeeper.com/user/api.linkedin.com/v1/companies/162479
    37. 37. Dataformats
    38. 38. Dataformats JSON
    39. 39. Dataformats JSON XML
    40. 40. Dataformats JSON XML JSONP
    41. 41. api.twitter.com/.../public_timeline.json
    42. 42. api.twitter.com/.../public_timeline.jsonapi.twitter.com/.../public_timeline.xml
    43. 43. api.twitter.com/.../public_timeline.jsonapi.twitter.com/.../public_timeline.xmlapi.twitter.com/.../public_timeline.rss
    44. 44. api.twitter.com/.../public_timeline.jsonapi.twitter.com/.../public_timeline.xmlapi.twitter.com/.../public_timeline.rssapi.twitter.com/.../public_timeline.atom
    45. 45. Security
    46. 46. Security HTTPS
    47. 47. Security HTTPS OAuth
    48. 48. Security HTTPS OAuth API Keys
    49. 49. HTTP is yourfriend
    50. 50. MethodsHTTP is your friend
    51. 51. Methods HTTPHTTP is your friend
    52. 52. Methods GET HTTPHTTP is your friend
    53. 53. Methods GET HTTP POSTHTTP is your friend
    54. 54. Methods GET HTTP POST PUTHTTP is your friend
    55. 55. Methods GET HTTP POST PUTHTTP is your friend DELETE
    56. 56. StatusCodesHTTP is your friend
    57. 57. StatusCodes HTTPHTTP is your friend
    58. 58. StatusCodes 200 OK HTTPHTTP is your friend
    59. 59. StatusCodes 200 OK HTTP 400 Bad RequestHTTP is your friend
    60. 60. StatusCodes 200 OK HTTP 401 Unauthorized 400 Bad RequestHTTP is your friend
    61. 61. StatusCodes 200 OK HTTP 401 Unauthorized 400 Bad RequestHTTP is your friend 405 Method Not Allowed
    62. 62. HTTPDON’TsHTTP is your friend
    63. 63. HTTPDON’Ts ‣ Use GET to update/ add dataHTTP is your friend
    64. 64. HTTPDON’Ts ‣ Use GET to update/ add data ‣ Use 200 OK when an error occursHTTP is your friend
    65. 65. GetStartedRemove thresholds
    66. 66. GetStarted Free and directRemove thresholds
    67. 67. GetStarted Free and direct Documentatio nRemove thresholds
    68. 68. GetStarted Free and direct Documentatio nRemove thresholds Clear terms and pricing
    69. 69. PredictableNo surprises
    70. 70. Predictable Predictable behaviorNo surprises
    71. 71. Predictable Predictable behavior Predictable managementNo surprises
    72. 72. Predictable Predictable behavior Predictable managementNo surprises Predictable upgrades
    73. 73. VersionsPlan for the future
    74. 74. Versions Things changePlan for the future
    75. 75. Versions Things change Make it easy for developersPlan for the future
    76. 76. Versions Things change Make it easy for developersPlan for the future Version in URI
    77. 77. api.twitter.com/1/users/show.json?...
    78. 78. api.twitter.com/1/users/show.json?...api.linkedin.com/v1/companies/162479
    79. 79. Scale
    80. 80. Scale Not unique to APIs
    81. 81. Cache isking
    82. 82. Cache isking Server & Client
    83. 83. Cache isking Server & Client HTTP Caching
    84. 84. Cache isking Server & Client HTTP Caching API Proxy
    85. 85. TrafficMo’ traffic,mo’ problems
    86. 86. Traffic Plan for traffic & concurrancyMo’ traffic,mo’ problems
    87. 87. Traffic Plan for traffic & concurrancy Rate limitsMo’ traffic,mo’ problems
    88. 88. Traffic Plan for traffic & concurrancy Rate limitsMo’ traffic,mo’ problems Response times
    89. 89. Needed VALUEforSuccess TECHNOLOGY DISCOVER API SCALE GET STARTED PREDICTABLE
    90. 90. QAandreas@dopter.se & @andreaskrohn mashup.se THANK YOU!

    ×