REST API多ID传递遇URL字符限制，寻求合规更优解决方案

Great question—handling large batches of IDs in REST APIs while staying true to convention is a super common headache. Let’s walk through some practical, compliant solutions that scale well as your data grows:

1. For your PATCH endpoint: Move IDs to the request body (no rule broken!) #

First up, let’s fix the low-hanging fruit: your current PATCH endpoint puts IDs in the URL path, but there’s no REST rule that says you can’t include batch identifiers in the request body for a bulk update.

Instead of PATCH /api/dailyEntries/1758,1759,1760,1761, rework it to:

@PatchMapping
public ResponseEntity<?> partialDailyEntryUpdate(@RequestBody BulkUpdateRequest request) throws DailyEntryNotFoundException {
    return dailyEntryService.partialDailyEntryUpdate(request.getIds(), request.getStatus());
}

// Simple DTO to hold batch update details
record BulkUpdateRequest(List<Long> ids, EntryStatus status) {}

This is fully compliant with REST—you’re sending a patch request to the dailyEntries collection resource, specifying which entries to update and the new status in the body. No URL length issues, clean, and intuitive.

2. For your GET endpoint: Use a POST to a dedicated search resource (practical & convention-aligned) #

GET requests shouldn’t have bodies (per HTTP spec recommendations), so switching to POST for bulk searches is a widely accepted workaround when URL length becomes a problem—as long as you frame it as a resource-oriented action.

Instead of cramming IDs into query params, create a search endpoint that accepts the ID list in the body:

@PostMapping("search/byProjectIds")
public ResponseEntity<List<DailyEntry>> getDailyEntriesFromProjectIds(@RequestBody ProjectIdRequest request) {
    return dailyEntryService.getDailyEntriesFromProjectIds(request.getIds());
}

// DTO to hold the list of project IDs
record ProjectIdRequest(long[] ids) {}

This avoids URL limits entirely. Purists might argue POST should create resources, but in practice, this is a standard pattern for bulk queries where the input is too large for a URL. It’s far cleaner than hacking around URL length limits.

3. Advanced: Temporary bulk query tickets (for extremely large ID sets) #

If you need to stick strictly to GET for retrieval (e.g., caching requirements), you can use a two-step approach:

1. Create a temporary query resource: POST your ID list to an endpoint that generates a unique ticket ID.

   @PostMapping("bulkQueries")
   public ResponseEntity<String> createBulkQuery(@RequestBody ProjectIdRequest request) {
       String ticketId = dailyEntryService.createBulkQueryTicket(request.getIds());
       return ResponseEntity.ok(ticketId);
   }
   

2. Retrieve results with GET: Use the ticket ID to fetch the results via a GET request.

   @GetMapping("bulkQueries/{ticketId}")
   public ResponseEntity<List<DailyEntry>> getBulkQueryResults(@PathVariable String ticketId) {
       return dailyEntryService.getBulkQueryResults(ticketId);
   }
   

You’ll need to handle cleanup of expired tickets (e.g., with a scheduled job), but this is perfect for very large ID sets or when you need to process the query asynchronously.

4. Pagination (if your use case allows) #

If the large ID set comes from a prior filtered query (e.g., "all projects in department X"), consider adding pagination to your existing endpoint instead of passing all IDs at once. For example:

@GetMapping("search/findByProjectIds")
public ResponseEntity<Page<DailyEntry>> getDailyEntriesFromProjectIds(
        @RequestParam long[] id,
        @RequestParam(defaultValue = "0") int page,
        @RequestParam(defaultValue = "100") int size) {
    return dailyEntryService.getDailyEntriesFromProjectIds(id, PageRequest.of(page, size));
}

This splits large result sets into manageable chunks, avoiding URL limits entirely. It’s ideal if users don’t need all entries in a single request.

Quick Recap #

• Bulk PATCH: Move IDs to the request body (most straightforward, fully compliant).
• Bulk GET: Use POST to a search endpoint (practical, widely accepted).
• Extremely large datasets: Temporary query tickets or pagination.

内容的提问来源于stack exchange，提问作者M.Dietz