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.

Teacher's Notes
Video Transcript
Downloads

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.

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

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

Introduction to REST APIs

Responses

Sign in