4:00 Why are we handling both GET and POST? Aren't we the ones who decide if we use GET or POST?

This post is quite old, but I do agree that the differences between the different HTTP request types is covered poorly here if this is a student's first introduction to them. To oversimplify for the sake of serving as a 'first' introduction, the differences are:

HTTP 'GET'

When a server receives a 'GET' request at a specific URL, the client is saying 'Hey, server, give me what you've got at <url>'. (The content-type header the server can include in its response is its way of replying 'Sure, here's [a webpage/a video/some JSON]' etc.). The 'GET' request can contain extra information in the URL itself, known as the query string: a set of extra key-value pairs in the form of ?key=val&key2=val2 at the end of the URL. The client is adding to its request 'Oh, and by the way, I want the <key> to be <value>'. This 'GET' request can be performed by typing the URL in to the navigation bar and hitting enter, or it can be submitted by a form where the user has filled out fields.

This is useful for information one wants to be contained in the URL. Think of a Google search: to again oversimplify, you type 'pineapple' in the search bar, you hit enter and you get taken to a page with the URL 'https://www.google.com/search?q=pineapple&<etc>'. As the details of the request are contained in the URL, you can do handy things like bookmark your search, or share it with a friend.

HTTP 'POST'

When a server receives a 'POST' request at a specific URL, the client is saying 'Hey, server, I've got this information for you' and handing it a 'sealed envelope' - the body of the request. The URL does not change, but the server can 'open the envelope' it was handed, look inside and act accordingly.

This is useful for information one wants to keep out of the URL. Think of a user submitting a password or payment information, and a server adding that information to a database, or adding conditions a web form can enforce (e.g. client-side form validation).

Now, to your question:

Why is the form's 'POST' request being handled when we could just make it send a 'GET' request instead?

In short, complexity is added to the server for the sake of simplicity for the user.

Were a form to send a 'GET' request for 'www.website.com/?username=chalkers', the client would say 'Hey, give me what you've got [at the root directory], and by the way, the username is 'chalkers'. (As a side note, this isn't ideal to be honest; 'what you've got' at the root directory would be a web form if no query string was sent and a profile page with a query string - pretty illogical. Remember, Google returns results at 'google.com/search?q=<query>' and not 'google.com/?q=<query>').

If the user wanted to go straight to the information for the profile by typing the URL in the navigation bar, this isn't a very user-friendly URL to have to write in each time. Instead, code is written so that when the user goes to 'www.website.com/chalkers', the client says to the server 'Hey, give me what you've got at website.com/chalkers'. Then, 'chalkers' is manually extracted from the end in order to respond with a profile page populated with the details of user 'chalkers'. To always keep the profile information at this URL construction, Mr. Chalkley constructs his site so that a profile can be accessed either by:

Option A:

• A 'GET' response to 'www.website.com/chalkers', returning a profile page populated with the profile 'chalkers'

or Option B:

• A 'GET' request to 'www.website.com', returning the search form. Filling it out with 'chalkers' and submitting it sends:
• A 'POST' request to 'www.website.com', whose body contains the username 'chalkers'
  • The body is parsed
  • The username 'chalkers' is extracted
  • The website uses this to redirect the browser, sending:
• A 'GET' request to 'www.website.com/chalkers', returning a profile page populated with the profile 'chalkers' (the request as per Option A)

Is this clearer now? Do let me know if I can help clarify anything else.