First off, this is a super common dilemma when building batch-focused APIs—your proposed approach works technically, but it comes with notable tradeoffs, and there are standardized patterns to handle bulk CRUD while sticking to HTTP best practices. Let’s break this down:

Key Drawbacks of Your Current Plan #

• Breaks HTTP Semantics: HTTP methods have well-defined, industry-agreed meanings. GET is meant for safe, idempotent resource retrieval—using POST here skips built-in caching (browsers/CDNs won’t cache POST requests, hurting performance for repeated reads) and confuses other developers who expect GET for fetching data. DELETE is inherently idempotent (repeating the request has the same effect), but POST isn’t—accidental duplicate requests could lead to unintended side effects, even if your app tries to handle it.
• Worse Debuggability & Observability: GET requests include parameters directly in the URL, making them easy to log, share, and debug. POST bodies are often excluded from default logs (for security or size reasons), so troubleshooting issues with bulk reads/deletes becomes way more work. Anyone looking at your API will also scratch their head at POST /read instead of the intuitive GET /resources.
• Violates REST Best Practices: REST APIs rely on method consistency to be self-documenting. Mixing POST for non-create operations makes your API harder to learn, maintain, and integrate with standard tools (like auto-generated API clients that rely on HTTP method conventions).
• Compatibility Risks: While you’re avoiding the "GET/DELETE with request body" compatibility issue (some clients/proxies don’t support this), you’re trading it for semantic inconsistency that can trip up future developers or tooling.

Established Patterns for Bulk CRUD Operations #

If you need to support batch inputs, here are more standardized approaches to consider:

1. Query Parameters for Small Batches #

For bulk reads where your list of names is short (under typical URL length limits, ~2000 characters), stick with GET and pass names as a comma-separated list or array in query params:

GET /resources?names=foo,bar,baz

This keeps HTTP semantics intact, allows caching, and is dead simple to debug.

2. Purpose-Built Batch Endpoints #

Create dedicated endpoints that clearly signal batch intent, using HTTP methods appropriately:

• Bulk create: POST /resources/batch (accepts array of {Name, Value}, returns same array)
• Bulk update: PUT /resources/batch (accepts array of {Name, Value}, returns updated array)
• Bulk read: POST /resources/batch/read (accepts array of Names, returns {Name, Value} array)
• Bulk delete: POST /resources/batch/delete (accepts array of Names, returns 204 No Content)
  This approach maintains clarity while supporting batch request bodies, and avoids misusing standard HTTP methods.

3. Use HTTP’s Flexible Spec (Carefully) #

If you want to keep standard methods, note that HTTP technically allows GET/DELETE with request bodies—though support is inconsistent across clients, proxies, and server frameworks. For bulk reads, you could do:

GET /resources
Content-Type: application/json

["foo", "bar", "baz"]

But test this thoroughly with your tech stack before committing. The same applies to DELETE /resources with a body of names—allowed, but not universally supported.

4. Consider GraphQL #

If batch operations are a core part of your API, GraphQL is purpose-built for this use case. A single query can fetch multiple resources by name, and mutations can handle bulk creates/updates/deletes in one request—all while maintaining clear, self-documenting semantics.

Final Takeaway #

Your proposed approach works, but the semantic and maintainability drawbacks are significant. Using purpose-built batch endpoints or sticking to standard methods with query params (where feasible) will make your API more intuitive, cacheable, and easier to work with long-term.

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