Well done for sticking with me.
Hope you're having a lot of fun.
Now I just want to talk about how to send data client side.
And what I mean by that is how do you define where and how to send the form data?
And right now I'm not going to be looking at AJAX.
I'm going to be looking at our traditional form, right?
Submitting it via the HTML form. And as a very quick recap,
you know the client/server architecture already, don't you?
We've got a browser, we've got a server.
The browser sends an HTTP request to a server.
The server responds with a response using the same protocol.
But you already know this, you already know this.
But let's talk about this in a bit more detail.
Specifically, I want to talk about the request part of it.
How does the browser define where and how to send the form data?
Well, as you know, we've got two attributes, right?
The action attribute and the method attribute that we place on the form element itself.
And these are the two most important attributes on the form element.
So then how exactly do they fit in?
Firstly, let's look at the action attribute. And the action attribute basically defines or tells the
browser where to send the data to. And its value must be a valid relative or absolute URL.
What happens if it's not provided at all?
If the attribute isn't provided, then the data is going to be sent to the URL of the page containing
the form aka the current page.
And because the action attribute is telling the browser where to send the data, the obvious counter
to that is that that action value or URL should be a file on the server that is listening to that data
and that can handle the data.
And as a bit of FYI, it is possible to specify a URL that uses HTTPS, you know, secure HTTP.
And when you do this, the data will be encrypted along with the rest of the request, even if the form
itself is hosted on an insecure page accessed via HTTP.
What's interesting is the flip can also work right?
If the form is hosted on a secure HTTP page, but you specify an insecure HTTP URL with the action attribute,
all browsers will display a security warning to the user each time they try and send the data because
the data is not going to be encrypted. Anyway,
that's just a bit of FYI.
So that's the action attribute.
You can kind of view the action and the server going hand in hand - it's the end point, right?
It's where the data should go to.
And then we've got this method attribute. And the method tells the browser how to send the data.
And the HTTP protocol does provide several ways to perform a request.
HTML form data can be transmitted via a number of different methods, specifically using a GET method
or a POST method. And to understand the differences between a GET and POST, you need to step back and
examine how HTTP works.
Every time you want to reach a resource on the web, the browser sends a request to a URL and an HTTP
request consists of two parts - a header and what else?
And a body.
That's right.
The header contains a set of global metadata about the browser's capabilities, and the body contains
information necessary to the server to process the specific request.
So then what is a GET method?
Well, the get method is the method used by the browser to ask the server to send back a given resource
and in this case the browser is going to send an empty body. Because the body is empty
if a form is sent using this method, the data sent to the server is going to be appended to the URL
as a series of name:value pairs.
And we've seen many examples of this in the course.
After the URL web address has ended, there's a question mark and then followed by the name value pairs
and each one is separated by an ampersand.
We've seen this many times. And then we've got this POST method.
The POST method is a little different to GET.
It's the method the browser uses to talk to the server
when asking for a response, that takes into account the data provided in the body of the HTTP request.
As you already know, if a form is sent using this method, the data is appended to the body, not the
URL of the HTTP request.
So there you have it.
This is how we define where and how to send form data to a server.
I know you already know this, but it's always good to recap, especially at the end, so everything
can just sink in.
Hope it's making sense.