Responses

So a user has sent a request for our API. 0:00 We've evaluated their query string, headers, and request format. 0:02 And of course, we've fetched the resources or collection that they wanted, now what? 0:07 Well, now we have to send them a response. 0:12 We'll, of course, 0:16 include the data, but we can send back quite a bit more information, too. 0:16 Like an HTTP request, an HTTP response also has headers. 0:21 In Postman, we can also view the response Headers. 0:28 The Content-Type header is used to specify what type of response is returned. 0:33 This should match the type that was requested. 0:39 For our treehouse example, when requesting the JSON format in the URL, or 0:42 the Accept header, the results are JSON. 0:47 When we remove this from the header and the URL, 0:52 the default Content-Type is HTML. 0:57 In the response Headers, we can see Access-Controls, 1:02 Cache-Controls, and many more. 1:05 Looking at the Status header, we come to another very important part of an API. 1:09 If you've been on the Internet for very long, you've probably come across a couple 1:16 of status codes like 200, 500, and the fairly common 404. 1:19 These status codes tells us a lot about the state of the bit of content, 1:26 and we can use them in an API to communicate the state of a request. 1:29 Generally, status codes are broken up into four chunks, each 100 numbers apart. 1:35 Status codes in the 200 to 299 range say that content is good and 1:41 everything is okay. 1:46 Some of these reference the fact that an action has been taken but 1:47 no error has happened. 1:51 For example, if a client posts a new record to a collection, 1:53 you'd want to use the 201 status code in your response 1:57 to let them know that the resource has been created. 2:01 Codes in the 300 to 399 range mean the request was understood, 2:04 but the requested resource is now located somewhere else. 2:10 These status codes are most often used to perform redirects to new URLs. 2:13 The third section, 2:20 status codes from 400 to 499 are errors typically generated by the client. 2:21 Maybe the request is wrongly constructed, which would be a 400. 2:28 Or it's for a resource that no longer exists, 404. 2:32 Or maybe there's a resource that only be read with Git and 2:36 no one is allowed to post, put or delete to it. 2:41 This should return a 405. 2:45 The 400 block is the largest of the HTTP status code blocks and 2:48 it's well worth looking over. 2:53 I'll put a link for more information in the teacher's notes. 2:55 Finally, let's talk about the 500 block. 2:58 Errors in the 500 to 599 range are all errors on the server's end. 3:02 The most used of these and the least descriptive is status code 500, 3:07 which just means that there's some sort of error on the server. 3:12 It's the equivalent of your server throwing up its hands and just quitting. 3:16 Look at the rest of the block though. 3:21 Because a lot of these are way better error messages than just sending 3:22 back a 500 to your client. 3:26 A lot of clients might handle all 500 block errors the same way. 3:28 But giving them better responses, 3:32 which will show up in their logs, makes you a better Internet citizen. 3:34 Again, I'll put a link in the teacher's notes. 3:38 Useful headers, correct status codes, appropriate format, and 3:42 useful data all combine to make a great HTTP response for an API. 3:46 But no Internet service is complete without one last, 3:52 very important ingredient, security. 3:55