Client-Server Model

Web browsers communicate with web servers using the HyperTextTransfer Protocol (HTTP). When you click a link on a web page, submit a form, or run a search, the browser sends an HTTP Request to the server.

This request includes:

• A URL identifying the target server and resource (e.g. an HTML file, a particular data point on the server, or a tool to run).
• A method that defines the required action (for example, to get a file or to save or update some data). The different methods/verbs and their associated actions are listed below:
  • GET: Get a specific resource (e.g. an HTML file containing information about a product, or a list of products). 
  • POST: Create a new resource (e.g. add a new article to a wiki, add a new contact to a database). 
  • HEAD: Get the metadata information about a specific resource without getting the body like GET would. You might for example use a HEAD request to find out the last time a resource was updated, and then only use the (more “expensive”) GET request to download the resource if it has changed. 
  • PUT: Update an existing resource (or create a new one if it doesn’t exist).
  • PATCH: Similar to PUT request, but instead of updating a whole object/resource it is used to apply partial modifications to a resource.
  • DELETE: Delete the specified resource.
  • TRACE, OPTIONS, CONNECT: These verbs are for less common/advanced tasks, so we won’t cover them here.
• Additional information can be encoded with the request (for example, HTML form data). Information can be encoded as:
  • URL query parameters: GET requests encode data in the URL sent to the server by adding name/value pairs onto the end of it — for example http://mysite.com?name=Fred&age=11. You always have a question mark (?) separating the rest of the URL from the URL query parameters, an equals sign (=) separating each name from its associated value, and an ampersand (&) separating each pair. URL query parameters are inherently “insecure” as they can be changed by users and then resubmitted. As a result URL query parameters/GET requests are not used for requests that update data on the server.
  • POST data: POST requests add new resources, the data for which is encoded within the request body.
  • Client-side cookies: Cookies contain session data about the client, including keys that the server can use to determine their login status and permissions/accesses to resources.

Web servers wait for client request messages, process them when they arrive, and reply to the web browser with an HTTP Response message. The response contains an HTTP Response status code indicating whether or not the request succeeded (e.g. “200 OK” for success, “404 Not Found” if the resource cannot be found, “403 Forbidden” if the user isn’t authorised to see the resource, etc). The body of a successful response to a GET request would contain the requested resource.

When an HTML page is returned it is rendered by the web browser. As part of processing the browser may discover links to other resources (e.g. an HTML page usually references JavaScript and CSS pages), and will send separate HTTP Requests to download these files.

When a user wants to navigate to a page, the browser sends an HTTP GET request specifying the URL of its HTML page. The server retrieves the requested document from its file system and returns an HTTP response containing the document and an HTTP Response status code of “200 OK” (indicating success). The server might return a different status code, for example “404 Not Found” if the file is not present on the server, or “301 Moved Permanently” if the file exists but has been redirected to a different location.

( https://developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Client-Server_overview )