I told you its not that bad.
We've seen the GET method, but now I want to talk about the POST method.
The POST method is a little bit different.
It's still the method the browser uses to talk to the server, but it's just talking in a slightly different
way.
It's basically the browser giving this request.
"Hey, server, look at this data and send me back a result."
That is also a very valid request, isn't it?
Our browser is very reasonable.
(sound: "Yes, I am not difficult"). But in this instance, there is one very, very important difference, and that...
is, the data is added to the body of the HTTP request.
And this means when the form is submitted using the POST method, you get no data appended to the
URL 😲.
And let me show you what this looks like, because you might be a bit confused at this point.
But again, it's not that difficult.
Let me hop over to the IDE and show you what this looks like. We've looked at the GET method,
I want us to now quickly discuss the POST method.
And this was the example we looked at with GET, remember. We have name, message and submit.
But now I want us to go to our IDE...
and the only change I want us to make, is I want us to change this to a POST request.
Now, if we go back to our browser and refresh, and type "Clyde" and type "Hello World"...
when I now click on submit, look at our URL. Nothing happens! Of course, the URI does not exist...
and that's why we get this error message.
The point I'm trying to make is that our data is not appended to the URL anymore, is it?
Well, where is it? Well, as I mentioned, it's in the body of the request. So to inspect our dev tools,
let's go to the network tag again...
let's just go back in the browser, refresh everything.
Here we go. Clyde.
Hello World. Annnnnnd let's submit. The method now in our...
dev tools is telling us it was a POST request.
We know it's failed because the URI doesn't exist, but ignore that for now.
We're not looking at that.
We are just looking at how the data is sent to the server...
in our case, a server that doesn't exist.
If we click on this, we get more detail about the request. And what's very cool is that we can see
it's a POST request.
If we scroll slightly down, we can see the host.
We can even see the content-length, which is pretty cool as well.
Another very important property that we're going to be talking about a lot later in this course, is this
content-type, this application/x-www-form-urlencoded.
That tells us that this is a POST request.
"Oh, Clyde.
But this is all good and well.
But where is our data?"
Well, we can keep scrolling down, and actually view the source data?
There it is.
Wow 🤩.
This blows my mind 🤯.
Isn't it awesome?
You can already tell that one of the main differences between the GET and POST request is where the
data is available. With the GET method,
we saw that the data was appended to the URL.
In this instance, we know it's attached to the body of the request.
There we go.
I hope it's starting to sink in now.
Remember, an HTTP request consists of two components, a header and a body.
And with the POST method, all your data from the form is appended to the body of the request.
Makes sense.
And now, last but not least.
Well, actually, it is least, it's not used that often...
the dialog...
what is that about 🤷‍♀️?
This value is specific to forms that are inside a dialogue element. And don't worry too much what it
is...
the <dialog> tag just defines a dialog box or sub-window.
It just makes it easy for us to create pop-up dialogues and modals on a web page.
And by having this value, it tells a browser to close the box when a submit event is fired on a
form. Again,
don't worry too much about the dialog...
you're not really going to use it that much.
By far, the two most important are the GET and POST methods.
But now you might be thinking you've mastered the GET and POST methods and the differences between
them, but there are a few other subtle differences we need to talk about.
So in the next lecture, let's just talk a little bit more about the GET versus the POST.
I really do hope you learning a ton in this course, but at the same time having fun, because that's what
it's about.
But enough "blibber-blabber".
See you in the next lecture.