Let's move on, let's move on, as I just said, I want us now to turn our attention to POST requests.
And do you remember what a POST request does?
Well, yes, when you make a POST request, the data of the form is kept in the body of the HTTP
request, it's not kept inside the URL as it is with a GET request.
That's the major distinguishing feature between a GET and a POST.
Have you got it?
Well, that's good, but because the data is kept in the body of the HTTP request, this means we have...
to decide, as a developer, how the data should be encoded.
And HTML forms provide three methods of encoding form data in an HTTP request, and you can already...
see the three types on the screen.
We've already looked at application/-...
x-www-form-urlencoded. Whew! That is a mouthful.
Remember what that is?
The request body uses the same format as the query string.
In other words, the body of the HTTP message will consist of one giant query string.
Each name:value pair will be separated by the ampersand, right.
And the name will be separated from the value with an equals sign.
So it looks pretty similar to our query string with the GET request,
right?
And that's right, because they both use the same formatting and that's all good and well.
But what's really powerful with a POST request is that we can set the encoding type to this multipart/-...
form-data, and this is used when you want to send binary data to a server.
I'm going to talk more about binary data later.
But binary data is just funky data.
It's just not text, it's not plain text, images, audio files, etc, etc..
Those are all, what's referred to in the development industry, as binary data, complicated data, funky
data.
When you're dealing with that, we're going to see that it's more efficient to send it with the encoding...
type set to multipart/form-data.
And next, we've got this text/plain type.
This text/plain type basically just sends it as is. Form fields are not...
URL encoded when sent to the server.
In other words, the data is sent without any encoding at all.
And for this reason, it's not recommended to use this type because it's difficult to predict its behavior.
So this text/plain type is very strange.
I ignore it when I code.
I never use it.
In fact, the HTML5 spec even says that this type is not reliable, reliably, reliably, reliably interpreted...
or interpretable by computers.
So it's only really intended to be human readable. For that reason...
avoid using it, as it's pretty much just meant for human understanding and not for machines.
So ignore text/plain.
I want to take a step back.
We've seen that effectively...
there are only really two types that you can set for that encoding type attribute,
right.
The first type, is that hideous long type, application/x-www-form-urlencoded ... I don't even know who comes up
with this stuff.
The second main type is that multipart/form-data. It's actually a lot easier to say 😂. But don't get lost
in the detail.
What is the purpose of this?
What is the purpose of both of these types?
That's right...
its sole purpose is just to transport the form data as name:value pairs, to your server.
That's all these types are trying to achieve. And they both achieve it, but in many cases one is more
efficient than the other.
So the bottom line is that depending on the size and type of data being transported over the web from
your form, one of these methods will be better than the other.
And in order to fully appreciate which you should use, well, you're going to need to understand how
it works under the hood.
I gotcha.
And that's exactly what we're doing.
So let's hop back into the lecture.
And now for some awesome party knowledge.
Did you know work was being done to add another type of encoding type: application/json.
But this has been abandoned. (sad trombone) So for the moment, we...
can pretty much rely on those two main types.
Got it?
So remember, this text/plain option is not really used. But don't take my word for it...
here is the snippet from HTML5 specification itself.
Now, I want to start looking at this POST request in more detail.
OK, so the default encoding type for the POST request is the same as a GET request.
Its application/x-www-form...
-urlencoded.
That's the default type.
Let me prove it to you.
Let's hop over to the Console.
Brilliant, brilliant, brilliant stuff.
We've seen a GET request, right.
This is exactly what we had last time on the screen.
But now I want to look at a POST request. So all we are going to do is jump back to our Visual Studio Code, change
the method to a POST, and now you are going to see things change.
So let's save the file,
go back to the browser. So here's our form, and I want to type the same thing.
WallyTheWarthog, and the favorite food of Wally can still be grass 🌿.
I want to inspect this, the Network tab. And what's going to happen now when we submit 🤷🏻‍♂️?
Well, firstly, you'll notice that we've got Content-Type set in the request header. And that Content-Type,
remember I said, its default value is application/x-www-form-urlencoded. Well, here is proof. We can...
see it in there.
The next thing I want to show you is that we don't have query string data anymore.
It's not in the URL, it's in the form body data itself.
And yes, it looks exactly the same as when we used the GET request,
right?
We've got each name:value pair separated by the ampersand, and each name and value itself is separated by...
an equal sign.
So that's pretty straightforward.
It looks exactly the same.
But we know now its in the body. And we know that Content-Type header is set.
This makes sense,
right?
Let's continue.
OK, so we've seen that the default type is application/x-www-form-...
urlencoded! Man, that is just such a long word 😵.
I can't stand it! Anyways...
my dear students, this type is okay, but it's not enough.
Why is it not enough?
Why do we need more?
Well, let's talk about files. Files or what's referred to in the development industry as binary data.
It's kind of weird to call it binary data because you and I know that machines can only speak binary...
at the end of the day.
So everything is binary, but it's just the lingo...
we use. Binary data we kind of refer to as complicated data.
All other data is just text data.
So if we're talking about boring plain old text, that is text data, we normally refer to files as binary...
data because there's rich formatting inside, there's images, all that kind of funky stuff. Files are binary...
data.
And what's super interesting is that HTTP is a text protocol, the keyword here being "text".
And this means that there has to be special requirements for handling binary data.
And what are these special requirements?
Well, this is exactly why we need this multipart/form-data encoding type.
And I want to look at an example now of using multipart/form-data.
But before I do, why is it called "multipart" 🤷‍♀️?
Well, did you know this attribute is usually set when users upload files, and the reason it's called...
multipart is because the form data can be divided into two parts, into multiple parts, one part for...
each file attached to the form, plus another part for the text data in the form, you know, like the...
user's name, surname, etc etc.
So it kind of intuitively makes sense, you're just splitting your form data into different parts, into
different categories of data.
But enough said, if you're anything like me, pictures 🖼️ speak more than a thousand words.
So let's jump over to the Console and let's see this in action.
Whew, this stuff is super, super interesting.
Now, I want to look at multipart/form-data.
So let's go back here to our code.
And I want to specify the encoding type, encoding type...
and I want that to be multipart/form-data. Now, usually we're going to be doing this when the user needs
to upload a file to the server.
But in our case right now, I just want to stick with simple text in the form so you can at least understand
how it works.
OK, so we are not going to change our form in any way.
What is going to happen now?
Let's go back to our browser.
Let's go back, refresh the entire page, clear the Network console, and let's do exactly the same
thing.
WallTheWarthog.
Favorite grass is food. Let's submit this. Now...
this is where things start getting very interesting.
Firstly, that Content-Type has changed to multipart/form-data, but now we've got this other weird value...
called "boundary", and it's got that horrible name next to it - all those hyphens 🤨.
What is that about?
Don't worry,
we're going to be talking about it shortly.
For now...
just know that the Content-Type has changed.
And then perhaps what might confuse you even more is when we scroll down into the format of this request,
we get this weird thing.
We can get this ... that same "boundary" name that we saw above inserted here,
and then we get Content-Disposition.
We get a whole lot of hyphens everywhere 🤯.
What is this all about?
My dear students, this is exactly the format of a multipart/form-data.
This is what happens when we specify that encoding type to multipart.
But let me jump into the lecture and explain this in a bit more detail.
I just wanted you to first see it in action.