Whether you are a front-end or back-end coder, HTTP requests are something you will definitely encounter. When sending requests, are you confused by the request parameters (referring to the data that needs to be carried in the request)? Let’s clarify this below.
Essential Knowledge: HTTP Message Format
- • Request Message: Request line (including request method, URI, protocol, and version) + Request headers + Blank line + Request body
- • Response Message: Response line (including protocol and version, status code, status description) + Response headers + Blank line + Response body
Classification of HTTP Request Parameters: By Location
The essence of HTTP parameters is the information carrier between the client and the server, and its format is closely related to its storage location. Based on the position of parameters in the HTTP protocol, they can be divided into four major types, each corresponding to specific usage scenarios and parsing logic.
(1) Path Parameters
Path parameters are parameters embedded in the URL path, separated by /, used to precisely locate server resources, and are a core design element of RESTful APIs.
Format Characteristics:
- • Location: After the domain name and before the query string (?), e.g., https://api.example.com/users/123/orders/45
- • Parsing Logic: The server extracts parameters by segmenting the URL path, requiring pre-defined parameter positions in the API routing
- • Special Handling: Chinese or special symbols (/,:,?) need URL encoding, for example, Chinese “张三” is encoded as %E5%BC%A0%E4%B8%89
Typical Scenarios:
- • Resource Unique Identifier: userId in /users/{userId} is used to locate a specific user
- • Hierarchical Resource Access: /users/{userId}/orders/{orderId} reflects the ownership relationship between users and orders
Development Notes:
- • Path parameters represent core attributes of resources and should not be used for non-locational parameters (e.g., pagination, filtering conditions)
- • Parameters must be explicitly declared in the backend routing, e.g., @PathVariable(“userId”) Long userId in Spring Boot
(2) Query Parameters
Query parameters are a collection of key-value pairs after the ? in the URL, used for additional operations such as filtering, sorting, and pagination of resources, commonly referred to as “? concatenation format”.
Format Characteristics:
- • Location: At the end of the URL, starting with ?, multiple parameters are separated by &, e.g., https://api.example.com/products?category=electronics&page=2&sort=price_asc
- • Data Structure: Supports key=value pairs, keys can be repeated (e.g., ?tags=java&tags=api indicates multiple tags)
- • Encoding Requirements: Chinese and special characters need URL encoding, spaces will be converted to + or %20
Typical Scenarios:
- • Data Filtering: ?status=active filters resources with an active status
- • Pagination Control: ?page=3&size=10 retrieves the 3rd page with 10 items per page
- • Sorting Rules: ?sort=createTime_desc sorts in descending order by creation time
Development Notes:
- • Not suitable for transmitting sensitive data (e.g., passwords), as parameters are exposed in the URL and can be logged
- • Data volume is limited by URL length (usually browsers limit to 2KB-8KB), avoid concatenating large numbers of parameters
- • Backend parsing must support multi-value parameters, e.g., req.query.tags in Node.js can retrieve an array [“java”, “api”]
(3) Header Parameters
Header parameters are stored in the HTTP request headers, used to transmit metadata, authentication information, processing instructions, and other contextual information. The server obtains relevant configurations by parsing the request headers.
This is also a type of “request parameter”, but generally, request headers do not contain business data.
Format Characteristics:
- • Location: Between the request line and the request body, existing in key: value format, e.g., Accept-Language: zh-CN,zh;q=0.8
- • Standard Fields: The HTTP protocol defines common header fields (e.g., Content-Type, Authorization), custom headers must be agreed upon with the server
- • Special Note: Cookies are essentially special fields stored in the request headers and are automatically carried with each request
Core Usage Scenarios:
- • Content Negotiation: Accept: application/json specifies the expected JSON format response from the client
- • Identity Authentication: Authorization: Bearer eyJhbGciOiJIUzI1Ni… transmits the JWT token
- • Request Tracking: X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5 custom tracking ID
- • Encoding Declaration: Content-Type: application/json;charset=utf-8 specifies the encoding of the request body
Development Notes:
- • Avoid storing business data in request headers, focus on metadata transmission
- • Custom headers are recommended to use the X- prefix (e.g., X-App-Version) to avoid conflicts with standard headers
- • Cookie data is sent with each request, and should not store large amounts of information (recommended not to exceed 4KB)
(4) Body Parameters
Body parameters are the data stored in the HTTP request body, used to transmit core business data for creating or updating resources, with the format specified by the Content-Type header field, and are the main data carrier for POST/PUT/PATCH requests.
Format Classification and Characteristics:
The format of the HTTP request body completely depends on the Content-Type field, and the backend must choose the corresponding parsing method based on this field. Common formats are as follows:
| Content-Type Value | Data Format | Applicable Scenarios | Example Code |
| application/x-www-form-urlencoded | Key-value pair concatenation (URL encoding) | Simple form submission | username=newUser&email=new%40example.com |
| multipart/form-data | Multi-part data (including boundary identifiers) | File upload + mixed form submission | ——boundaryContent-Disposition: form-data; name=”file”; filename=”test.jpg”… |
| application/json | JSON object format | Complex structured data transmission | {“username”: “newUser”, “email”: “[email protected]”} |
| text/plain | Plain text string | Simple text data (e.g., logs) | User login failed: invalid password |
| application/xml | XML tag structure | Traditional system data exchange | newUser |
Typical Scenarios:
- • User Registration: POST request transmits username, password, etc. in application/json format
- • File Upload: POST request transmits images + descriptive text in multipart/form-data format
- • Form Submission: Traditional web pages submit login forms in application/x-www-form-urlencoded format
Development Notes:
- • GET requests are not recommended to use body parameters (some servers may ignore them)
- • Sensitive data transmission should be combined with HTTPS encryption to avoid plaintext transmission
- • The backend must have a unified parsing logic, for example, Spring Boot automatically parses JSON format through @RequestBody