1 00:00:00,250 --> 00:00:05,340 An API that can't keep up with the demand is almost worse than no API at all. 2 00:00:05,340 --> 00:00:09,830 Users won't always stick around until your service comes back up in off-hours. 3 00:00:09,830 --> 00:00:13,610 The first step towards making sure that your API is available for 4 00:00:13,610 --> 00:00:16,550 clients is usually caching. 5 00:00:16,550 --> 00:00:23,000 A cache is usually a service that runs in memory to hold recently requested results, 6 00:00:23,000 --> 00:00:26,840 like a newly created record, or a large data set. 7 00:00:26,840 --> 00:00:31,650 This helps to prevent database calls and even costly calculations on your data. 8 00:00:32,760 --> 00:00:37,699 Maybe your data is spread across several databases, or tables in your database. 9 00:00:37,699 --> 00:00:40,672 And gathering up all of that information, sorting it, 10 00:00:40,672 --> 00:00:44,490 and presenting it to the user, takes several seconds. 11 00:00:44,490 --> 00:00:50,030 Putting that final calculated data into a cache means that subsequent lookups 12 00:00:50,030 --> 00:00:55,140 only take as long as required for your cache to find and return the right key. 13 00:00:56,630 --> 00:00:59,520 Memcached is a very popular cache, but 14 00:00:59,520 --> 00:01:03,270 there are many different pieces of software available to handle this. 15 00:01:03,270 --> 00:01:06,370 You may have to experiment to find the one that's right for your API. 16 00:01:07,370 --> 00:01:11,110 All include links to some common caches in the teacher's note. 17 00:01:11,110 --> 00:01:14,900 Also keep in mind that third party APIs that you may be using 18 00:01:14,900 --> 00:01:18,340 are probably implementing some sort of caching. 19 00:01:18,340 --> 00:01:21,190 This can sometimes cause unexpected results 20 00:01:21,190 --> 00:01:22,930 if the caches is not working properly. 21 00:01:24,170 --> 00:01:27,450 All the cashing in the world won't save you from a large enough 22 00:01:27,450 --> 00:01:29,430 deluge of requests. 23 00:01:29,430 --> 00:01:34,830 The second step on our path to having a resilient API is rate limiting. 24 00:01:34,830 --> 00:01:36,940 Rate limiting is a pretty simple idea. 25 00:01:38,180 --> 00:01:42,380 Each user is allowed a certain number of requests to your API 26 00:01:42,380 --> 00:01:44,350 in a given time period. 27 00:01:44,350 --> 00:01:46,820 Once a user exhausts their allotment, 28 00:01:46,820 --> 00:01:51,240 they'll have to wait until the timer runs out so they can get more. 29 00:01:51,240 --> 00:01:55,010 This helps to prevent users from just flooding you with requests. 30 00:01:55,010 --> 00:02:00,390 And also helps to prevent distributed denial of service or DDOS attacks. 31 00:02:01,550 --> 00:02:04,670 And out final step is authentication. 32 00:02:04,670 --> 00:02:09,450 It's a little hard to rate limit users when you don't have any idea which request 33 00:02:09,450 --> 00:02:11,440 is from which user. 34 00:02:11,440 --> 00:02:13,040 That whole state listing, remember. 35 00:02:14,130 --> 00:02:17,720 And what if we need to restrict certain information to certain users? 36 00:02:17,720 --> 00:02:21,780 Again, we need some way to verify that a user is who they say they are. 37 00:02:22,870 --> 00:02:26,240 Different APIs handle authentication differently. 38 00:02:26,240 --> 00:02:30,800 When building an API, how your user gets accounts is up to you, and 39 00:02:30,800 --> 00:02:32,750 whatever tools you're using. 40 00:02:32,750 --> 00:02:36,860 Let's go over a few ways that authentication requests can be handled. 41 00:02:37,980 --> 00:02:42,670 The most common way you'll encounter is the use of API tokens. 42 00:02:42,670 --> 00:02:48,540 When setting up an API account, a user is given a token and a secret pair. 43 00:02:48,540 --> 00:02:53,050 The user will pass those credentials when making a request to the server. 44 00:02:53,050 --> 00:02:57,550 This allows the API's server to verify the communication. 45 00:02:57,550 --> 00:03:01,530 The server takes the pair of credentials and checks that they're active, 46 00:03:01,530 --> 00:03:03,860 proper users in the database. 47 00:03:03,860 --> 00:03:07,415 It's a lot like including a user name and password when you log into a site. 48 00:03:07,415 --> 00:03:11,516 [SOUND] Users need to include their token with every 49 00:03:11,516 --> 00:03:15,434 request because of the statelessness of HTTP. 50 00:03:15,434 --> 00:03:19,702 Which means authentication happens with each request. 51 00:03:19,702 --> 00:03:25,505 Most of the time, the token and secret are included as keys in the JSON or 52 00:03:25,505 --> 00:03:28,232 XML data that a client will send. 53 00:03:28,232 --> 00:03:29,658 But it is possible for 54 00:03:29,658 --> 00:03:34,423 them to be included in the authentication headers in the HTTP request. 55 00:03:34,423 --> 00:03:39,069 Make sure you understand where this information will be included when 56 00:03:39,069 --> 00:03:41,121 consuming or building an API. 57 00:03:41,121 --> 00:03:44,543 There are other method of handling authentication, 58 00:03:44,543 --> 00:03:48,870 like cross realm authentication, HTTP Digest and others. 59 00:03:48,870 --> 00:03:52,555 But a lot of them will be specific to be API or tools that you're using. 60 00:03:52,555 --> 00:03:56,122 Postman, the tool that we've been using to test out our API, 61 00:03:56,122 --> 00:04:00,802 should allow you to send any type of authentication request that you encounter. 62 00:04:00,802 --> 00:04:04,158 When building an API, a lot of what we've covered so far, 63 00:04:04,158 --> 00:04:09,093 caching, parsing requests, and preparing responses, authentication and more, 64 00:04:09,093 --> 00:04:13,660 will depend on your framework, language, and tools of choice. 65 00:04:13,660 --> 00:04:16,910 Be sure to research the best approach to building an API 66 00:04:16,910 --> 00:04:19,360 with your language of choice before diving in.