For more quality interview questions and study notes, visit KamaCoder Notes:https://notes.kamacoder.com
“What are the HTTP request methods?”
unsetunsetBrief Answerunsetunset
-
HTTP/1.1 originally defined 8 core request methods (RFC 2616, 1999):
-
GET: Retrieve resources, parameters in the URL, safe and idempotent. -
POST: Submit data (e.g., form data), may change server state. -
PUT: Full update of resources, idempotent. -
DELETE: Delete resources, idempotent. -
HEAD: Similar to GET, only returns response headers. -
OPTIONS: Query supported request methods by the server. -
TRACE: Echo the request (usually disabled due to security risks). -
CONNECT: Establish a proxy tunnel (e.g., HTTPS).
-
PATCH is an extended method added later through RFC 5789 (2010), not included in the original HTTP/1.1 definition.
unsetunsetDetailed Answerunsetunset
8 Core Request Methods Defined in HTTP/1.1
-
GET:
-
Purpose: Request specified resources, parameters passed via URL. -
Characteristics: Safe (does not modify server resources), idempotent (consistent results on repeated requests), cacheable (response can be cached by browsers or proxies). -
Scenarios: Data queries, page loads.
-
Purpose: Submit data (data carried in the request body). -
Characteristics: Not safe (may modify server state, e.g., create an order), not idempotent (repeated submissions may yield different results, e.g., multiple order creations). -
Scenarios: Form submissions, triggering business logic.
-
Purpose: Full update of resources (client must provide complete data). -
Characteristics: Idempotent (repeated updates yield the same result, such as updating the same resource), not safe (may overwrite changes made by other users). -
Scenarios: Full update of user information.
-
Purpose: Delete specified resources. -
Characteristics: Idempotent (repeated deletions of the same resource yield the same effect, e.g., returns the same status when the resource does not exist), not safe (directly modifies server state). -
Scenarios: Deleting articles, users, and other resources.
-
Purpose: Similar to GET, but the server does not return the response body, only the response headers. -
Characteristics: Lightweight (saves bandwidth, used to check resource existence or updates, such as Last-Modified), safe, idempotent. -
Scenarios: Checking resource existence or updates, e.g., validating link validity, resource cache status.
-
Purpose: Query supported request methods by the server or check cross-origin request permissions. -
Characteristics: Preflight request: Browsers automatically send OPTIONS requests for CORS validation. -
Scenarios: Preflight requests before cross-origin API calls.
-
Purpose: Echo client requests (for debugging). -
Characteristics: May pose security risks (e.g., XST attacks), usually disabled.
-
Purpose: Establish a proxy tunnel (e.g., HTTPS). -
Characteristics: Handled by the server/proxy, not directly exposed to the business layer.
Extended Methods (Not Native to HTTP/1.1)
-
PATCH:
-
Description: From RFC 5789 (2010), note that RFC 5789 (2010) is an independent extension specification that only adds the PATCH method, requiring explicit support, and does not involve HTTP version updates. -
Purpose: Partially update resources, requiring a defined data format (e.g., JSON Patch), clients only submit fields that need modification. -
Characteristics: Not idempotent (multiple partial updates may lead to different results), flexible (requires defined data formats). -
Scenarios: Modifying partial user information (e.g., nickname).
unsetunsetKnowledge Expansionunsetunset
Development History of HTTP Request Methods
-
As shown in the following picture:
Why are only seven methods defined in the HttpServlet source code?
-
HttpServlet is designed based on HTTP/1.1 (RFC 2616, 1999), and among the 8 methods defined in the original specification RFC 2616, TRACE
andCONNECT
are not recommended for direct use by developers for the following reasons:
-
TRACE
is usually disabled due to security risks (e.g., XST attacks). -
CONNECT
is handled by the server layer (e.g., Tomcat), requiring no intervention from business code.
TRACE
.Request Methods Supported by Different HTTP Versions
-
HTTP/1.0 (RFC 1945, 1996): GET, POST, HEAD. -
HTTP/1.1 (RFC 2616, 1999): GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, CONNECT. -
HTTP/1.1 (RFC 7231, 2014): Same as RFC 2616 (1999), currently the core specification of HTTP/1.1. -
HTTP/2 (RFC 7540, 2015): Compatible with HTTP/1.1 methods, no new methods added. -
HTTP/3 (RFC 9114, 2022): Also compatible, no new methods added.
The Eight-Legged Training Camp Officially Opens Today (February 19)!
Why is there an Eight-Legged Training Camp?
Currently, there is a lot of material on eight-legged essays (interview questions), but everyone still faces the following troubles when memorizing them:
-
Too many eight-legged contents, which questions should be looked at within limited time? -
Feels like the content cannot be finished, self-learning lacks rhythm. -
Have seen many eight-legged essays, but cannot express them during interviews. -
Feeling nervous during the interview: Who am I? Where am I? What am I doing?
To avoid stuttering during interviews and speaking ineffectively, KamaCoder Training Camp has developed a brand new training model, which is recording check-ins!
Daily eight-legged tasks will be assigned, requiring everyone to record their answers in the system to complete the daily check-in.
Details can be found here: Details of Interview Blitz (Eight-Legged Training Camp)
Effects of the Eight-Legged Training Camp
This is feedback from past recording friends:
Check Opening Time and Register for the Training Camp
Scan the WeChat code to see the recent opening times of the training camp: (The 16th session officially opens today (February 19))
Any questions regarding the training camp can be addressed by scanning the customer service code below:

Welcome recording friends to take notes, click “Read the original text” to go directly to 【KamaCoder Notes】