Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll

Introduction to REST APIs

Preview

Start a free Courses trial
to watch this video

Sign up for Treehouse

Responses

3:59 with Alena Holligan

Once a client sends us a request, we need to generate and send back a response. There's more to a response, though, than just the data content.

NOTE: the URL endpoint for treehouse profiles has changed slightly. Be sure to use https://teamtreehouse.com/profiles/alenaholligan.json instead.

Here is a list of all of the HTTP header fields you're likely to find or create on a response.

And since you might need them, here is a list of HTTP status codes.

Related Discussions

Have questions about this video? Start a discussion with the community and Treehouse staff.

Sign up

    Related Discussions

    Have questions about this video? Start a discussion with the community and Treehouse staff.

    Sign up

    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

    You need to sign up for Treehouse in order to download course files.

    Sign up

      You need to sign up for Treehouse in order to set up Workspace

      Sign up