We just saw what a request to a server looks like, and
we mentioned that the request used was a GET request, but what does it mean for
a request to be a GET request.
A GET request is a type of HTTP request where a client requests a specified
resource from a server.
For example, the client could make a GET request for an image on a server and
then the server could return it back.
A GET request is just one of several kinds of HTTP requests,
also called HTTP methods, and it's the most common.
Now you'll note,
in this course I'm going to avoid using the term HTTP method to much because I
don't want to confuse the term with what we know as methods in Swift.
Let's look more closely at GET request by reusing or
example of Udacity's homepage.
When you visit Udacity's homepage in a web browser,
you're making a GET request.
By typing in the URL udacity.com in the address bar, you're specify a resource,
in this case you'd ask the homepage from a server somewhere in the network.
And you're saying, hey, get this for me.
And when we hit enter, the request is made and we can see that it's a success
because the server's responded with Udacity's homepage.
But there's so much more happening than meets the eye when you make this request
on a web browser.
To show you what's really happening under the hood,
I'm going to use the Chrome app called Postman.
If you want to follow along I'll post the download link
in the instructor notes, but
you'll need to already have installed Google Chrome in order to use it.
Okay, so here's the Postman app.
At the top bar, you can make a request, much like we did in the web browser.
But here to the left, we can also specify the type of request.
For this request, we'll leave it as the default, which is GET.
Now let's type in the URL for Udacity's homepage, and hit Send.
Wow, okay, so there's a lot to observer here.
Let's go step by step.
For now, I'm going to hide this side panel,
which shows a history of the request that we've made.
Here at the top we have some tabs for Authorization, Headers,
Pre-request script, and Tests.
We're going to skip these for now and come back to them later.
let's focus our attention here on the Body.
This is the response that the server returned when we made a GET request for
you Udacity's homepage.
But it doesn't look anything like the homepage we're used to seeing.
It's just a bunch of html, CSS and JavaScript code.
That's because all of this code is normally loaded, interpreted, and
rendered by our web browser.
If we click on the Preview option, we can see a low fidelity version of what
this would look like if it was loaded by Chrome.
Next, I want to look at the Status section where it says, 200 OK.
This is what is know as a status code.
A status code gives us a quick indication of whether the HTTP request
succeeded, failed, or something else.
There are many different possible status codes that can be returned for
an HTTP request.
I'll post a link in the instructor notes if you want to read about them more.
The most important thing to note is that anytime we get a status code that begins
with a 2, it means the request was successful.
Let's hover over the status code so
we can see a little bit of information about what it means.
It says that a 200 status code is the standard response for
a successful HTTP request, and
that the actual response depends on the type of request that was used.
Because we used a GET request up here,
we're seeing the entity that corresponds to the requested resource,
which in this case was the Udacity homepage and all of it's code.
Also, at the bottom of this description, it mentions a new type of request,
called a POST request, which we'll talk about later in this course.
The next thing we see is the time it took to execute our request
in milliseconds, which was 1,350 milliseconds.
This is important to keep in mind.
When we make requests over the network it does take some amount of time for
us to get a response.
It's not always instantaneous.
So when we start making these requests in code, we'll have to consider what we
want our app to do while it's waiting on a response.
Now let's try a different URL.
This time I'm going to use a URL that I know doesn't refer to a page on
Udacity's website.
I'll go ahead and hit Send.
And this time we get a response, but notice the new status code,
which is 404.
If we hover over the status code it says the requested resource can't be found.
Anytime we see a status code that begins with a 4 or
5, it indicates some kind of error.
Bu, even though we have an error, we still get a response.
If you look at the the response in Preview mode, we see that it's
a page that says, we're sorry, what you're looking for doesn't exist.
This is commonly referred to as a 404 page.
Not all websites have these, but the awesome engineers at Udacity
have created this 404 page so in case you request a page that doesn't exist,
you still see something that feels like Udacity's normal website.
Okay, I have one more example.
This time let's request an image instead of a webpage.
This is the kind of request we'll make when we build the app for this lesson.
I'll type in my request and hit Send.
This time we get a image as a response instead of HTML code.
And that's the last point I want to make here,
when we make HTTP requests the data that we get back can be images, text,
HTML code and various other types of media.
If you have some time I highly recommend that you download Postman yourself and
experiment.
I'll also post some links in the instructor notes for other similar
tools in case you don't use Google Chrome as your normal browser.