For uploading multiple distinct document types like those in EquipmentLegal, you have two viable design paths depending on the UX needs, document type clarity, and maintenance expectations.

✅ Option 1: Dedicated Endpoints per Document Type

This is clean, descriptive, and explicit:

java
CopyEdit
@PostMapping("/{equipmentId}/legal/purchase")
public ResponseEntity<String> uploadPurchaseAgreement(@PathVariable UUID equipmentId, @RequestParam MultipartFile file)

@PostMapping("/{equipmentId}/legal/warranty")
public ResponseEntity<String> uploadWarranty(@PathVariable UUID equipmentId, @RequestParam MultipartFile file)

@PostMapping("/{equipmentId}/legal/manual")
public ResponseEntity<String> uploadManual(@PathVariable UUID equipmentId, @RequestParam MultipartFile file)

@PostMapping("/{equipmentId}/legal/inspection")
public ResponseEntity<String> uploadInspectionCertificate(@PathVariable UUID equipmentId, @RequestParam MultipartFile file)

✅ Pros

• Great for API documentation (Swagger).
• Easy to enforce validation or special logic for each document type.
• Clear and straightforward from a frontend/integration POV.

❌ Cons

• Can feel repetitive and boilerplate-heavy.
• Changes to document taxonomy require more controller/service updates.

🚀 Option 2: Smart Dynamic Endpoint with Type Enum

Instead of multiple methods, you expose one upload endpoint and a documentType parameter:

java
CopyEdit
public enum EquipmentLegalDocumentType {
    PURCHASE, WARRANTY, MANUAL, INSPECTION
}

@PostMapping("/{equipmentId}/legal/upload")
public ResponseEntity<String> uploadLegalDocument(
        @PathVariable UUID equipmentId,
        @RequestParam EquipmentLegalDocumentType type,
        @RequestParam MultipartFile file)

✅ Pros

• Much DRYer and scalable.
• Adding a new type = just adding an enum value.
• Easier to generalize service logic (switch(type) or map type to entity field).