I’m working on a Spring Boot application where I need to create REST endpoints that can handle multiple files at once. For the upload endpoint, users should be able to send several files in one request. For the download endpoint, I need to return multiple files back to the client.
Here’s what I’m trying to achieve:
@PostMapping("/batch-upload")
public ResponseEntity<String> handleMultipleFiles(@RequestParam("documents") MultipartFile[] documents) {
// Process multiple uploaded files
return ResponseEntity.ok("Files processed");
}
@GetMapping("/batch-download")
public ResponseEntity<List<Resource>> getMultipleFiles(@RequestParam String requestId) {
// Return multiple files to client
return ResponseEntity.ok(fileList);
}
For each file I’m working with, I need access to the original filename, the content type, and the actual byte data. Creating a zip archive isn’t an option for my use case since the client application needs to process each file individually.
I’m primarily using Spring Boot but I’m open to integrating other libraries if needed. Has anyone implemented similar functionality before? What’s the recommended approach for this kind of multi-file handling?
I hit this same issue last year and found a different approach that might help. Skip trying to handle multiple downloads in one response - use streaming with multipart/mixed content instead. Your upload approach is right, but add file size validation and async processing for better performance:
The client gets all files in one response but can process them individually by parsing the multipart content. Really useful when you need to keep file metadata and avoid multiple HTTP requests.
Been there many times. Your upload endpoint looks solid, but downloads need a different approach - you can’t return multiple files in one HTTP response.
Here’s what works:
Uploads - your current approach is fine, just add validation:
@PostMapping("/batch-upload")
public ResponseEntity<Map<String, String>> handleMultipleFiles(@RequestParam("documents") MultipartFile[] documents) {
Map<String, String> results = new HashMap<>();
for (MultipartFile file : documents) {
if (!file.isEmpty()) {
String filename = file.getOriginalFilename();
String contentType = file.getContentType();
// Store file and track results
results.put(filename, "success");
}
}
return ResponseEntity.ok(results);
}
Downloads - two solid options:
Return file metadata with individual download links:
@GetMapping("/batch-download")
public void downloadMultipleFiles(@RequestParam String requestId, HttpServletResponse response) {
response.setContentType("multipart/x-mixed-replace; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW");
// Write each file as separate part
}
I usually go with option 1 - it’s cleaner and gives the client more control.
I’ve built similar multi-file endpoints in production, and your upload approach looks solid. The main challenge is downloads since HTTP responses can only contain one body.
Your upload code’s on the right track. I usually add some validation and processing:
@PostMapping("/batch-upload")
public ResponseEntity<Map<String, String>> handleMultipleFiles(@RequestParam("documents") MultipartFile[] documents) {
Map<String, String> results = new HashMap<>();
for (MultipartFile file : documents) {
if (!file.isEmpty()) {
String originalName = file.getOriginalFilename();
String contentType = file.getContentType();
byte[] bytes = file.getBytes();
// Your processing logic here
String fileId = saveFile(originalName, contentType, bytes);
results.put(originalName, fileId);
}
}
return ResponseEntity.ok(results);
}
For downloads, you can’t return multiple files in one HTTP response. I usually go with:
Return metadata with individual download URLs for each file.
Use multipart response format (like email attachments).
I’ve dealt with this exact scenario in a document management system. The trick is handling downloads properly without overcomplicating things.
For uploads, your MultipartFile array approach works well. Store each file with a unique identifier and track the relationship to the original request:
For downloads, I use a hybrid approach. Create a batch download endpoint that sets up a temporary download session, then provide individual file endpoints:
This gives clients flexibility to download all files or pick specific ones based on what they need. The session approach also handles security and cleans up temporary resources.
I built something similar but ditched Spring Boot file handling completely. Way too much boilerplate and memory issues with large files.
I automated everything with Latenode instead. It handles multipart uploads, stores files in cloud storage, and creates download links automatically.
Here’s the setup: Create a webhook endpoint in Latenode that receives your multipart files. The workflow extracts each file, validates size/type, uploads to S3 or Google Drive, then returns JSON with all the file metadata and download URLs.
For downloads, Latenode generates secure temporary URLs. Your client gets a simple API response with direct download links - no more dealing with Spring Boot streaming or multipart responses.
Best part? Adding file processing like virus scanning, format conversion, or thumbnails is just drag and drop in the visual editor.
Processed over 50TB last quarter this way. Zero crashes and way less code to maintain than Spring Boot.
multipart streaming is a pain to handle on the client side. i just return file metadata first, then let the client grab files one by one when it needs them. much simpler and you get proper error handling for each file.
