The concept of web framework

Web application framework, or simply "web framework", is actually a way to build Web applications. From a simple blogging system to a complex rich AJAX application, every page on the web is generated by writing code. I find that a lot of people are interested in learning about web framework technology, such as flask or this Django, but many people don't understand what a web framework is, or how they work. In this article, I'll explore topics that are based on the web framework that is repeatedly overlooked. After reading this article, you should start with a deeper understanding of what the web framework is and why they exist. This will make it much easier to learn a new web framework and make it a wise choice to use a different framework.

How does the Web work?

Before we discuss the framework, we need to understand how the Web works. To do this, we'll dig deeper into what happens when you enter a URL in the browser and press ENTER. Open a new tab in your browser and browse the http://www.jeffknupp.com. We discussed what the browser did to show this page (not concerned about DNS queries).

Web Server

Each page is sent as HTML to your browser, and HTML is a language that browsers use to describe the content and structure of the page. The apps that are responsible for sending HTML to browsers are called "Web servers," And what makes you wonder is that the machines that run them are often called Web servers.

However, it is important to understand that the last thing that all Web apps have to do is send HTML to the browser. Regardless of the complexity of the application's logic, the end result is always to send HTML to the browser (I deliberately ignore the application in response to different types of data like JSON or CSS, because it is conceptually the same).

How does a Web application know what to send to a browser? It sends anything that the browser requests.

HTTP

The browser downloads a Web site from a Web server (or an application server) using the HTTP protocol, which is based on a request-response (Request-response) model. The client (your browser) requests data from the Web application running on the physical machine, and the Web application responds to your browser request in turn.

It is important to remember that communication is always initiated by the client (your browser), and that the server (that is, the Web server) has no way to create a link to send the data to your browser without a request. If you receive data from a Web server, it must be because your browser has sent the request.

HTTP Methods

In the HTTP protocol, each message is associated with methods (method or verb), and different HTTP methods correspond to different types of requests that the client can send, which in turn represents the different intentions of the client. For example, requesting HTML for a Web page is logically different from submitting a form, so these two behaviors require a different approach.

HTTP get

The Get method is, as it sounds, get (request) data from the Web server. A GET request is one of the most common HTTP requests to the current location, and there is no need to do anything with the Web application responding to the HTML of the request page in the course of a request. In particular, Web applications in the results of a GET request should not change the state of the application (for example, you cannot create a new account based on a GET request). It is for this reason that get requests are generally considered "safe" because they do not cause the application to change.

HTTP POST

Obviously, in addition to the Simple view page, there should be more operations to interact with the site. We can also send data to the application, such as through a form. To achieve this, a different type of request method is required: POST. POST requests typically carry data entered by the user, and the Web application receives some behavior after it has been received. By entering your information in a form, you log on to a Web site, which is the POST form's data to the Web application.

Unlike get requests, POST requests typically cause changes in the application state. In our example, after the form POST, a new account is created. Unlike get requests, a POST request does not always generate a new HTML page to send to the client, but rather the response code (response code) that the client uses to determine whether the operation was successful.

Htttp Response Codes

Typically, the Web server returns a response code of 200, meaning, "I've done what you asked me to do and everything is fine." The response code is always a three-digit number, and the Web application sends a code that indicates the result of a given request at the same time as each response. Response Code 200 literally means "OK", which is the code that responds to a GET request that is used in most cases. However, for POST requests, there may be 204 ("no Content") sent back, meaning "everything is fine, but I'm not going to show you anything."

The POST request will still send a special URL, which may be different from the page submitting the data, which is critical. Or take our login as an example, the form may be on the Www.foo.com/signup page, but clicking Submit may cause post requests with form data to be sent to the Www.foo.com/process_sigup. Where the POST request is to be sent is specifically marked in the form's HTML.