1 00:00:00,230 --> 00:00:02,860 So a user has sent a request for our API. 2 00:00:02,860 --> 00:00:06,360 We've evaluated their query string, headers, and request format. 3 00:00:07,400 --> 00:00:12,990 And of course, we've fetched the resources or collection that they wanted, now what? 4 00:00:12,990 --> 00:00:15,000 Well, now we have to send them a response. 5 00:00:16,190 --> 00:00:16,710 We'll, of course, 6 00:00:16,710 --> 00:00:20,260 include the data, but we can send back quite a bit more information, too. 7 00:00:21,270 --> 00:00:26,410 Like an HTTP request, an HTTP response also has headers. 8 00:00:28,030 --> 00:00:31,360 In Postman, we can also view the response Headers. 9 00:00:33,122 --> 00:00:39,120 The Content-Type header is used to specify what type of response is returned. 10 00:00:39,120 --> 00:00:42,210 This should match the type that was requested. 11 00:00:42,210 --> 00:00:47,320 For our treehouse example, when requesting the JSON format in the URL, or 12 00:00:47,320 --> 00:00:50,780 the Accept header, the results are JSON. 13 00:00:52,980 --> 00:00:57,311 When we remove this from the header and the URL, 14 00:00:57,311 --> 00:01:00,680 the default Content-Type is HTML. 15 00:01:02,330 --> 00:01:05,907 In the response Headers, we can see Access-Controls, 16 00:01:05,907 --> 00:01:08,170 Cache-Controls, and many more. 17 00:01:09,490 --> 00:01:14,410 Looking at the Status header, we come to another very important part of an API. 18 00:01:16,160 --> 00:01:19,980 If you've been on the Internet for very long, you've probably come across a couple 19 00:01:19,980 --> 00:01:26,150 of status codes like 200, 500, and the fairly common 404. 20 00:01:26,150 --> 00:01:29,900 These status codes tells us a lot about the state of the bit of content, 21 00:01:29,900 --> 00:01:34,120 and we can use them in an API to communicate the state of a request. 22 00:01:35,140 --> 00:01:41,290 Generally, status codes are broken up into four chunks, each 100 numbers apart. 23 00:01:41,290 --> 00:01:46,240 Status codes in the 200 to 299 range say that content is good and 24 00:01:46,240 --> 00:01:47,950 everything is okay. 25 00:01:47,950 --> 00:01:51,390 Some of these reference the fact that an action has been taken but 26 00:01:51,390 --> 00:01:53,210 no error has happened. 27 00:01:53,210 --> 00:01:57,460 For example, if a client posts a new record to a collection, 28 00:01:57,460 --> 00:02:01,220 you'd want to use the 201 status code in your response 29 00:02:01,220 --> 00:02:03,730 to let them know that the resource has been created. 30 00:02:04,800 --> 00:02:10,030 Codes in the 300 to 399 range mean the request was understood, 31 00:02:10,030 --> 00:02:13,980 but the requested resource is now located somewhere else. 32 00:02:13,980 --> 00:02:19,020 These status codes are most often used to perform redirects to new URLs. 33 00:02:20,130 --> 00:02:21,460 The third section, 34 00:02:21,460 --> 00:02:28,160 status codes from 400 to 499 are errors typically generated by the client. 35 00:02:28,160 --> 00:02:32,870 Maybe the request is wrongly constructed, which would be a 400. 36 00:02:32,870 --> 00:02:36,350 Or it's for a resource that no longer exists, 404. 37 00:02:36,350 --> 00:02:41,164 Or maybe there's a resource that only be read with Git and 38 00:02:41,164 --> 00:02:45,760 no one is allowed to post, put or delete to it. 39 00:02:45,760 --> 00:02:47,604 This should return a 405. 40 00:02:48,690 --> 00:02:53,510 The 400 block is the largest of the HTTP status code blocks and 41 00:02:53,510 --> 00:02:55,390 it's well worth looking over. 42 00:02:55,390 --> 00:02:58,810 I'll put a link for more information in the teacher's notes. 43 00:02:58,810 --> 00:03:00,940 Finally, let's talk about the 500 block. 44 00:03:02,070 --> 00:03:07,780 Errors in the 500 to 599 range are all errors on the server's end. 45 00:03:07,780 --> 00:03:12,070 The most used of these and the least descriptive is status code 500, 46 00:03:12,070 --> 00:03:16,660 which just means that there's some sort of error on the server. 47 00:03:16,660 --> 00:03:19,960 It's the equivalent of your server throwing up its hands and just quitting. 48 00:03:21,040 --> 00:03:22,710 Look at the rest of the block though. 49 00:03:22,710 --> 00:03:26,280 Because a lot of these are way better error messages than just sending 50 00:03:26,280 --> 00:03:28,500 back a 500 to your client. 51 00:03:28,500 --> 00:03:32,650 A lot of clients might handle all 500 block errors the same way. 52 00:03:32,650 --> 00:03:34,550 But giving them better responses, 53 00:03:34,550 --> 00:03:38,650 which will show up in their logs, makes you a better Internet citizen. 54 00:03:38,650 --> 00:03:40,760 Again, I'll put a link in the teacher's notes. 55 00:03:42,340 --> 00:03:46,310 Useful headers, correct status codes, appropriate format, and 56 00:03:46,310 --> 00:03:52,280 useful data all combine to make a great HTTP response for an API. 57 00:03:52,280 --> 00:03:55,820 But no Internet service is complete without one last, 58 00:03:55,820 --> 00:03:58,590 very important ingredient, security.