Follow us, bookmark us, and meet us every day at 7:30 for daily Java content sharing.
Technical Analysis
HTTP messages are divided into request messages (client -> server) and response messages (server -> client).
1. Structure of HTTP Request Message
The request message is used to tell the server “what I want to do.”
# ----------------------------------------------------
# 1. Request Line: Tells the server the “action” and “target”
# ----------------------------------------------------
GET /users/123/profile HTTP/1.1
# Method | URI (Resource Path) | HTTP Version
# ----------------------------------------------------
# 2. Header Fields: Tells the server “who I am” and “how I want to receive”
# ----------------------------------------------------
Host: api.example.com
User-Agent: Mozilla/5.0
Accept-Encoding: gzip, deflate
Cookie: sessionId=XYZ
Connection: keep-alive
# ----------------------------------------------------
# 3. Empty Line: Marks the end of header information
# ----------------------------------------------------
# This is a required empty line (CRLF)
# ----------------------------------------------------
# 4. Message Body: Only used for requests that submit data like POST, PUT, PATCH
# ----------------------------------------------------
{
"email": "[email protected]" # Actual submitted data (e.g., JSON)
}2. Structure of HTTP Response Message
The response message is used to tell the client “what the request result is.”
# ----------------------------------------------------
# 1. Status Line: Tells the client the “result” and “status”
# ----------------------------------------------------
HTTP/1.1 200 OK
# HTTP Version | Status Code | Status Description
# ----------------------------------------------------
# 2. Header Fields: Tells the client “the type of returned data” and “cache policy”
# ----------------------------------------------------
Content-Type: application/json
Content-Length: 512
Date: Sun, 24 Nov 2025 09:00:00 GMT
Cache-Control: max-age=3600
# ----------------------------------------------------
# 3. Empty Line: Marks the end of header information
# ----------------------------------------------------
# This is a required empty line (CRLF)
# ----------------------------------------------------
# 4. Message Body: Contains the resource requested by the client or error information
# ----------------------------------------------------
{
"id": 123,
"username": "Alice" # Actual returned data (e.g., user JSON information)
}Story Scenario: Sending an International Order Package
- • The Entire Package (HTTP Message): The complete communication content from sending to receiving.
- • Sender (Client): The client.
- • Recipient (Server): The server.
1. Request Line — “The Main Label on the Package”
- • Function: A definitive instruction.
- • Request: Like the **“action label”** on the front of the package. The label says: “Please perform: query operation (
<span>GET</span>), target is: Alice’s profile (<span>/users/alice</span>)”. This is the first information the courier (network) needs to see. - • Response: Like the **“inspection result label”** on the front of the package. The label says: “Inspection result: 200 (success)” or “Inspection result: 404 (target not found)”. This is the conclusion the recipient needs to know first.
2. Header Fields — “Detailed Item List”
- • Function: Metadata and rules of the package.
- • Request Header: Like the “sender list” on the side of the package. It details: “Sender: Your browser version (
<span>User-Agent</span>), where the package comes from (<span>Host</span>), whether there is a note in the package (<span>Cookie</span>), and what kind of compression I can accept (<span>Accept-Encoding</span>).” - • Response Header: Like the “package contents and handling instructions” on the side of the package. It details: “The package contains JSON format (
<span>Content-Type</span>), the total weight of the package is 512 grams (<span>Content-Length</span>), and how long you can keep this package in your warehouse (<span>Cache-Control</span>).”
3. Empty Line — “Anti-Cheating Seal”
- • Function: Physical separation.
- • Metaphor: Just like after all labels and lists are affixed to the package, the logistics company will use a prominent, blank tape to completely separate the label area from the actual goods area. This empty line tells the parser: “Attention! The above are the rules, the rules have ended! The following is the main content!”
4. Message Body — “The Actual Goods in the Package”
- • Function: The actual data carrier.
- • Request Body: Just like the actual goods packed inside the box when you send a package (such as submitted username, password, and other form data). In a
<span>GET</span>request, the box is empty. - • Response Body: Just like when the recipient opens the box, the actual items inside (such as returned HTML code, JSON data, images, etc.).
Story Summary:
| Message Composition | Technical Definition | Metaphor of International Package |
| Request Line | Method/Status Code/URI/Version | Main instruction on the front of the package (what action/what result) |
| Header | Key-value pair metadata | Detailed list and handling rules on the side |
| Empty Line | Required CRLF | Physical separation tape |
| Message Body | Actual data or resource | The actual goods inside the box |
Conclusion: The structure of HTTP messages is the foundation of the protocol. It clearly separates metadata (rules and descriptions, i.e., request line and headers) from payload (actual data, i.e., message body) and delineates the boundary with an empty line. This structure ensures that regardless of the content being transmitted, both the client and server can efficiently and accurately parse the instructions and data.
Recommended Reading Click the title to jump
50 Java Code Examples: Mastering Lambda Expressions and Stream API
16 Java Code “Pain Points” Major Overhaul: “General Writing” VS “Advanced Writing” Ultimate Showdown, Watch Code Quality Soar!
Why Senior Java Developers Love Using the Strategy Pattern
Selected Java Code Snippets: Better Writing for 10 Common Programming Scenarios
Enhancing Java Code Reliability: 5 Best Practices for Exception Handling
Why You Rarely See if-else in Senior Developers’ Code, Because They All Use This…
Still Crazy Injecting Other Services in Service? You Should Have Used Spring’s Event Mechanism Long Ago
Did you gain something from this article? Please share it with more people.
Follow ‘Java Content’ and bookmark it to enhance your Java skills
❤️ Give a 'Recommendation', it's the biggest support ❤️