是否存在将多个API调用合并为单个HTTP请求的通用标准？

Great question! Dealing with batch operations while staying true to REST principles is a common pain point, especially when you need compatibility with HTTP/1.x. Let's break down the standard and community-approved solutions for bundling multiple API calls into a single HTTP request:

While not yet a formal RFC, the HTTP Batch Requests draft is widely adopted by major cloud providers (like Google Cloud Storage, Microsoft Graph API) and has become a de facto standard for this use case. It works by wrapping multiple full HTTP requests into a single multipart/form-data request body, using unique boundary separators to distinguish each sub-request.

Here's a simplified example matching the GCS format you referenced:

--batch_unique_boundary_123
Content-Type: application/http
Content-Transfer-Encoding: binary

DELETE /storage/v1/b/my-bucket/o/file1 HTTP/1.1
Host: storage.googleapis.com

--batch_unique_boundary_123
Content-Type: application/http
Content-Transfer-Encoding: binary

PUT /storage/v1/b/my-bucket/o/file2 HTTP/1.1
Host: storage.googleapis.com
Content-Type: application/json

{"name": "updated-file-name.txt"}

--batch_unique_boundary_123--

Each sub-request follows standard HTTP semantics (method, path, headers, body), so your server can parse and process them independently, then return a corresponding multipart response with results for each operation. This approach stays fully aligned with REST principles since it doesn't introduce custom action endpoints.

If you want a lighter-weight alternative without multipart complexity, a widely accepted community practice is to send an array of operation instructions via a standard POST request to a collection endpoint (e.g., POST /files/batch). The request body defines each operation's method, target resource, and data:

[
  {
    "method": "DELETE",
    "resourceId": "file-123"
  },
  {
    "method": "PATCH",
    "resourceId": "file-456",
    "payload": {"metadata": {"tag": "archive"}}
  }
]

While this requires custom server-side parsing, it's extremely easy to implement for both clients and servers, and works seamlessly with HTTP/1.x. Just ensure the operation semantics mirror your single-resource endpoints (e.g., a batch DELETE should behave the same as individual DELETE requests to each resource).

For APIs following the OData specification, there's a formal standard called OData Batch (defined in OASIS OData v4.0). It builds on multipart HTTP requests but adds stricter rules, including support for transactional batches (all operations succeed or all roll back) and dependency between sub-requests. If your API adheres to OData, this is a turnkey standards-compliant solution.

As you noted, custom action-oriented endpoints break REST's resource-centric design. REST emphasizes manipulating resources (nouns) via standard HTTP methods (verbs), whereas batchDelete introduces a verb-based endpoint that doesn't map to a specific resource. The solutions above maintain REST consistency by treating batch operations as a collection of standard resource interactions bundled into one request.

内容的提问来源于stack exchange，提问作者Oleg Korobenko