Home GitHub

Delete API

Last updated

This page explains how DELETE /del/{path} moves files or folders into the trash, and how to restore them.

Request

Item Value
Method DELETE
Path /del/{path}, where {path} is a file or folder under storage/image/upload/; a trailing / is stripped
Body Not needed

Move Rules

Rule Behavior
Destination storage/image/upload/.trash/{YYYY-MM-DD}/{last segment}
Date UTC date (toISOString()); items deleted before 08:00 Taiwan time land in the previous day
Name collision When the destination exists, _{millisecond timestamp} is appended; files keep their extension (a_1791311009904.jpg), folders get it appended directly (x_1791311009904)
Original structure Not kept: only the last segment is used, so blog/2025/a.jpg and news/a.jpg land side by side
Cache Conversions in cache/ are not removed, so GET /c/img/... keeps serving the cached result

Responses

Status Type Body
200 JSON { "success": 1, "message": "檔案已移動至垃圾桶: {absolute server path}" }
200 JSON Folder: 檔案夾已移動至垃圾桶: {absolute server path}
400 Text 未指定檔案/檔案夾
404 Text 檔案/檔案夾不存在
500 Text System error message

Examples

# Delete a file
curl -fsS -X DELETE \
  http://localhost:8080/del/blog/2025/ERftP1gTS7WCTeJ8_1744080848530.jpg

# Delete a whole folder
curl -fsS -X DELETE http://localhost:8080/del/blog/2025

Restore

Move the item from the trash back to its original path (with Docker Compose the host path is ./image/):

mv ./image/upload/.trash/2026-10-06/ERftP1gTS7WCTeJ8_1744080848530.jpg \
   ./image/upload/blog/2025/

The trash is never emptied automatically. Through Nginx, /.trash paths are denied, so the trash cannot be read or deleted via the API.

中文