• A request line (REQUEST LINE) that specifies the HTTP method, target resource, and protocol version;
  
• Request headers (REQUEST HEADERS) that provide additional information about the request and the client;
  
• A request body (REQUEST BODY) that contains data being sent to the server, such as form data or file uploads.
  

--- Request Line
GET http://www.mtitek.com HTTP/1.1
--- Request Headers
[Client]
Accept: image/gif, image/jpeg,
image/pjpeg, image/pjpeg, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1)
[Transport]
Connection: Keep-Alive
Host: www.mtitek.com
[Cache]
If-Modified-Since: Sun, 12 Dec 2010 03:00:56 GMT
If-None-Match: "236018a-5f9-4972dcbd68a00"
[BLANK LINE]
--- Request Body
[EMPTY]

1. Request Line
   The request line is the first line of an HTTP request and defines the fundamental action being requested. It follows a specific format that includes three essential components separated by spaces:
   HTTP_METHOD URI HTTP_VERSION
   

   • HTTP_METHOD: the HTTP method that specifies the type of action to perform (GET, POST, HEAD, OPTIONS, TRACE, PUT, DELETE). The method determines how the server should process the request.
     
   • URI: the Uniform Resource Identifier that specifies the exact resource being requested. This can be an absolute URL or a relative path depending on the context.
     
   • HTTP_VERSION: the version of the HTTP protocol being used for communication. Common versions include HTTP/1.0, HTTP/1.1, and HTTP/2.
     

   
   The request line must be terminated with a carriage return and line feed (CRLF) sequence. This line break separates the request line from the subsequent request headers.
   
   Example:
   GET http://www.mtitek.com HTTP/1.1
   
2. Request Headers
   Request headers provide additional metadata about the request, the client, and the desired response format. Each header follows a standardized name-value format:
   HEADER_NAME: HEADER_VALUE1, HEADER_VALUE2, ..., HEADER_VALUEn
   

   • HEADER_NAME: the standardized name of the request header that identifies its purpose and meaning;
     
   • HEADER_VALUE{1}, HEADER_VALUE{2}, ...,HEADER_VALUE{n}: the values associated with the header. Multiple values are supported for certain headers.
     
   • Each header name uniquely identifies a specific type of metadata being transmitted.
     
   • Headers can contain multiple comma-separated values to provide additional flexibility.
     
   • Header names are case-insensitive and are separated from their values by a colon (:) followed by optional whitespace;
     
   • When multiple values exist for a single header, they are separated by commas (,);
     
   • Each complete header is separated from the next by a line break (CRLF).
     

   
   Common request headers include Accept (specifying acceptable response formats), User-Agent (identifying the client software), Authorization (providing authentication credentials), and Content-Type (describing the format of request body data). An empty line marks the end of the headers section and separates it from the optional request body.
   
   Example:
   

   Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, */*
   Accept-Encoding: gzip, deflate
   Accept-Language: en-us
   User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1)
   [BLANK LINE]

3. Request Body (optional)
   The request body is an optional section that contains data being transmitted from the client to the server. Not all HTTP methods utilize a request body, and its presence depends on the specific operation being performed.
   
   The request body can contain various types of data:
   

   • Form parameters and values from an HTML form submission, typically encoded as application/x-www-form-urlencoded or multipart/form-data.
     
   • Files to upload (UPLOAD) to the server, commonly used in file upload scenarios and content management systems.
     
   • JSON or XML data for API requests, enabling structured data exchange between client and server applications.
     
   • Binary data such as images, documents, or other media files being transmitted to the server.
     

   
   The Content-Type header specifies the format and encoding of the request body data, allowing the server to properly parse and process the incoming information.
   

• A response line (RESPONSE LINE) that indicates the protocol version, status code, and status description;
  
• Response headers (RESPONSE HEADERS) that provide metadata about the response and the server;
  
• A response body (RESPONSE BODY) that contains the actual content being delivered to the client.
  

--- Response Line
HTTP/1.1 200 OK
--- Response Headers
[Miscellaneous]
Server: Apache/2.2.3
[Transport]
Connection: close
[Cache]
Date: Sun, 12 Dec 2010 20:06:52 GMT
[BLANK LINE]
--- Response Body
"<html><head><title>mtitek.com</title>...

1. Response Line
   The response line is the first line of an HTTP response and provides essential information about the server's response to the client's request. It follows a standardized format:
   HTTP_VERSION RESPONSE_CODE RESPONSE_CODE_DESCRIPTION
   

   • HTTP_VERSION: the version of the HTTP protocol used by the server in its response. This should match or be compatible with the version specified in the request.
     
   • RESPONSE_CODE: a three-digit numeric code that indicates the result of the request. Response codes are grouped into categories: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), and 5xx (server error).
     
   • RESPONSE_CODE_DESCRIPTION: a human-readable phrase that briefly describes the meaning of the response code, making it easier to understand the response status.
     

   
   Common response codes include 200 (OK), 404 (Not Found), 500 (Internal Server Error), and 302 (Found/Redirect). The response line is terminated with a line break that separates it from the response headers.
   
   Example:
   

   HTTP/1.1 200 OK

2. Response Headers
   Response headers provide important metadata about the server's response, the content being delivered, and instructions for the client. They follow the same format as request headers:
   HEADER_NAME: HEADER_VALUE{1}, HEADER_VALUE{2}, ..., HEADER_VALUE{n}
   

   • HEADER_NAME: the standardized name of the response header that indicates the type of information being provided.
     
   • HEADER_VALUE{1}, HEADER_VALUE{2}, ..., HEADER_VALUE{n}: the values associated with the header, providing specific details about the response.
     
   • Each header name serves a specific purpose in describing the response characteristics.
     
   • Headers may contain multiple values to provide comprehensive information.
     
   • Header names are case-insensitive and are separated from their values by a colon (:) followed by optional whitespace;
     
   • Multiple values within a single header are separated by commas (,);
     
   • Each header is separated from the next by a line break (CRLF).
     

   
   Important response headers include Content-Type (specifying the format of the response body), Content-Length (indicating the size of the response body), Set-Cookie (sending cookies to the client), and Cache-Control (providing caching instructions). A blank line separates the response headers from the response body.
   
   Example:
   

   Server: Apache/2.2.3
   Connection: Close
   [BLANK LINE]

3. The Response Body (Optional)
   The response body contains the actual content that the server is delivering to the client in response to the request. The presence and format of the response body depend on the HTTP method used and the type of resource being accessed.
   
   The response body may contain various types of content including HTML pages for web browsing, JSON or XML data for API responses, image files, documents, stylesheets, JavaScript code, or any other digital content. The Content-Type header in the response specifies the exact format and encoding of the body content, enabling the client to properly process and display the received data.
   

1. GET
   The GET method is used to retrieve data from a server and is the most commonly used HTTP method. GET requests are designed to be safe and idempotent, meaning they should not modify server state and can be repeated multiple times without different effects.
   
   A GET request is triggered by:
   

   • Entering a URL directly into the browser's address bar, which initiates a GET request for the specified resource;
     
   • Clicking on a hyperlink on a webpage, causing the browser to navigate to the linked resource;
     
   • Submitting an HTML form where the METHOD attribute is set to "GET", either by clicking a submit button or using JavaScript form submission;
     
   • Making an Ajax call using JavaScript to fetch data without refreshing the entire page.
     

   
   When using GET requests, any parameters are appended to the URL as a query string in the format:
   (http://www.mtitek.com/webapp?PARAM_NAME_1=PARAM_VALUE_1&PARAM_NAME_2=PARAM_VALUE_2).
   
   GET requests have limitations on the amount of data that can be transmitted via the URL, and sensitive information should not be included in GET parameters since they are visible in browser history, server logs, and may be cached.
   
2. POST
   The POST method is used to send data to a server for processing, typically resulting in a change in server state or side effects. POST requests are not idempotent, meaning multiple identical requests may have different effects.
   
   A POST request is triggered by:
   

   • Submitting an HTML form where the METHOD attribute is set to "POST", providing a secure way to transmit form data including sensitive information like passwords.
     
   • Making an Ajax call with the POST method to send data to the server for processing or storage.
     

   
   Unlike GET requests, POST parameters are placed in the request body rather than the URL, providing better security and allowing for larger amounts of data to be transmitted. The Content-Type header specifies how the data in the request body is encoded.
   
   The POST method can be used to upload files to a server, submit form data, create new resources, or trigger server-side processing. When used for file uploads, POST behaves similarly to the PUT method but allows the server to determine where the uploaded content should be stored.
   
3. HEAD
   The HEAD method is functionally identical to the GET method but with one crucial difference: the server returns only the response headers without the response body. This makes HEAD requests efficient for obtaining metadata about a resource without downloading its entire content.
   
   When a HEAD and GET request are made to the same resource, the response lines and headers should be identical, but the HEAD response will not include the actual content. This method is particularly useful for checking if a resource exists, determining its size, verifying if it has been modified since a certain date, or obtaining caching information without the overhead of downloading the full content.
   
   HEAD requests are commonly used by web crawlers, caching systems, and applications that need to verify resource status or gather metadata efficiently.
   
4. OPTIONS
   The OPTIONS method is used to determine the communication options available for a specific resource or server. This method allows clients to discover which HTTP methods are supported for a particular resource without actually performing those operations.
   
   The server responds to an OPTIONS request with information about supported methods, allowed headers, and other communication options. This method is particularly important in Cross-Origin Resource Sharing (CORS) scenarios, where browsers send preflight OPTIONS requests to determine if a cross-origin request is allowed before sending the actual request.
   
   OPTIONS requests help clients understand the capabilities and restrictions of a server or specific resource, enabling more intelligent and compliant HTTP communication.
   
5. PUT
   The PUT method is used to upload or update a resource at a specific location on the server. PUT requests are idempotent, meaning that multiple identical requests should have the same effect as a single request.
   
   When using PUT, the client specifies exactly where the resource should be stored on the server through the request URI. If a resource already exists at the specified location, PUT will replace its content entirely with the new data. The server's response code indicates whether the resource was newly created (201 Created) or an existing resource was updated (200 OK).
   
   Unlike the POST method, which typically allows the server to determine where uploaded content should be stored, PUT gives the client explicit control over the resource location. This makes PUT particularly useful for RESTful APIs where clients need to create or update resources at predictable URLs.
   
   PUT is commonly used for file uploads, content updates, and resource creation in web services and content management systems.
   
6. DELETE
   The DELETE method is used to request the removal of a specified resource from the server. Like PUT, DELETE requests are idempotent, meaning that multiple DELETE requests for the same resource should have the same effect.
   
   When a DELETE request is processed successfully, the server responds with a status code indicating the result of the operation. A response code of 200 (OK) indicates that the resource has been successfully deleted and the response includes additional information. A code of 202 (Accepted) indicates that the deletion request has been accepted but the actual deletion will be performed asynchronously at a later time. A code of 204 (No Content) indicates successful deletion with no additional response content.
   
   DELETE requests are fundamental to RESTful API design and content management systems, allowing clients to remove unwanted resources programmatically.