2

I have a doubt. When is a GET request sent. I mean, I have seen a lot of people using if request.method == 'GET', when they render the form for the first time, but when the form is submitted, they do a `POST' request.

While they explicitly mention when defining the form in html that the method will be 'POST', they don't do the same for 'GET' request which is made when an empty form is requested.

How does django know it's a GET request?

And, why is it done so?

Thanks,

Abhishek Arya
  • 450
  • 4
  • 16
  • `GET` typically makes *no* changes to the database (and other persistent structures). `POST` typically does. You have other request methods as well like `PUT`, `PATCH`, `OPTION`, etc. – Willem Van Onsem Jun 18 '18 at 16:56
  • Thanks, @WillemVanOnsem. Actually, my doubt is, when I click a signup page, it open in front of me an empty page and this was done using a GET request. How does Django get to know it's a GET request when nothing was mentioned explicitly. And, why it made a GET request? Is this the default behavior – Abhishek Arya Jun 18 '18 at 16:58

3 Answers3

0

Actually Django is based on HTTP responses-requests. HTTP is fully textuall. So Django parses each request and finds in its header information about what kind of request is it. I may be mistaken in details, but as I understand when server receives request - Django creates it's object request, which contains all the data from HTTP. And then you decide if you need a specific action on GET or POST and you check the type of request with request.method.
P.S. And yes, by default each request is GET.

Chiefir
  • 2,561
  • 1
  • 27
  • 46
0

GET

A GET is usually used to retrieve information. Typically a GET function has no side-effects (this means that data in the database is not changed, that no files in the filesystem are modified, etc.).

Strictly speaking this is not always true, since some webservers log requests (themselves) and thus add an entry to the database that a specific user visited a specific page at a specific timestamp, etc.

A typical GET request is idempotent. This means that there is no difference between doing a query one time, or multiple times (two times, three times, five times, thousand times).

GET queries are therefore typically used to provide static content, as well as pages that contain data about one or more entries, search queries, etc.

POST

POST on the other hand typically ships with data (in the POST parameters), and usually the idea is that something is done with this data that creates a change in the persistent structures of the webserver. For example creating a new entry in some table, or updating the table with the values that are provided. Since these operations are not always idempotent, it can be dangerous if the user refreshes the page in the browser (since that could for example create two orders, instead of the single order the user actually wanted to create).

Therefore in Django a POST request will typically result in some changes to the database, and a redirect as result. This means that the user will typically obtain a new address, and perform a GET request on that page (and that GET is idempotent, hence it will not construct a new order).

PUT, PATCH and DELETE

Besides the popular GET and POST, there are other typical requests a client can make to a webserver. For example PUT, PATCH and DELETE.

PUT

PUT is the twin of a POST request. The main difference is that the URI it hits, specifies what entry to construct or update. PUT is usually an idempotent operation.

This means that if we would for example perform a POST server.com/blog/create to create a blog, PUT will typically look like PUT server.com/blog/123/. So we specify the id in advance. In case the object does not yet exists, a webserver will typically construct one. In case the entity already exists, a new entity will typically be constructed for that URI. So performing the same PUT operation twice, should have no effect.

Note that in case of a PUT request, typically one should specify all fields. The fields that are not specified will typically be filled in with default values (in case such values exist). We thus do not really "update" the entity: we destroy the old entity and create a new one in case that entity already exists.

PATCH

PATCH is a variant of PUT that updates the entity, instead of creating a new one. The fields that are thus missing in a PATCH request, typically remain the same as the values in the "old" entity so to speak.

DELETE

Like the name already suggests, if we perform a DELETE server.com/blog/123/ request, then we will typically remove the corresponding element.

Some servers do not immediately remove the corresponding element. You can see it as scheduling the object for deletion, so sometimes the object is later removed. The DELETE request, thus typically means that you signal the server to eventually remove the entity.

Willem Van Onsem
  • 443,496
  • 30
  • 428
  • 555
0

I'm not an expert but I think Django "knows" this because like all things on the Internet it uses the HTTP protocol. There are several HTTP methods. If not specified the default method will always be GET

rephlexions
  • 16
  • 3