Preview
Video Player
00:00
00:00
Responses
3:59Once 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.
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