שיטת HTTP DELETE

DELETE מסיר משאב מהשרת. הבקשה פשוטה. ההשלכות — לא.

הבקשה

בקשות DELETE הן מינימליסטיות. ה-URL מזהה את מה שיש להסיר. כותרות מטפלות באימות. בדרך כלל אין גוף לבקשה.

DELETE /articles/12345 HTTP/1.1
Host: api.example.com
Authorization: Bearer token123

לאחר DELETE מוצלח, בקשות GET לאותו URL אמורות להחזיר 404 Not Found. המשאב נעלם.

התגובה

204 No Content הוא תגובת ההצלחה הנפוצה ביותר — המשאב נמחק, ואין מה להוסיף:

HTTP/1.1 204 No Content

200 OK מתאים כאשר ברצונך להחזיר מידע על מה שנמחק:

{
  "id": 12345,
  "deleted_at": "2024-05-15T10:30:00Z"
}

202 Accepted מסמן שהמחיקה נמצאת בתור אך טרם הושלמה — שימושי בעת הסרת כמויות גדולות של נתונים.

404 Not Found פירושו שהמשאב אינו קיים. אבל זה מעלה שאלה מעניינת.

409 Conflict מצביע על כך שלא ניתן למחוק את המשאב — אולי יש לו תלויות, או שכללים עסקיים מונעים את הסרתו.

פרדוקס האידמפוטנטיות

DELETE הוא אידמפוטנטי: קריאה אליו מספר פעמים אמורה להניב את אותה תוצאה כמו קריאה בודדת. אבל אפשר להרוס משהו רק פעם אחת. מה קורה כאשר אתה מוחק משהו שכבר נמחק?

מחנה ראשון — להחזיר 404: "המשאב אינו קיים. אי אפשר למחוק דבר שאינו שם."

DELETE /articles/12345
→ בקשה ראשונה: 204 No Content
→ בקשה שנייה: 404 Not Found

מחנה שני — להחזיר 204: "ביקשת שהמשאב הזה לא יתקיים. משימה הושלמה."

DELETE /articles/12345
→ בקשה ראשונה: 204 No Content  
→ בקשה שנייה: 204 No Content

לשתי העמדות יש הגיון. גישת 404 מיידעת אותך אם הבקשה שלך אכן עשתה משהו. גישת 204 מדגישה את המצב הסופי — המשאב נעלם, וזה מה שרצית.

רוב ממשקי ה-API המודרניים מחזירים 404, אך הוויכוח חושף משהו אמיתי. האם מחיקה היא פעולה ("הסר את הדבר הזה") או תוצאה ("וודא שהדבר הזה נעדר")? מפרט HTTP לא קובע. אתה צריך להחליט.

מחיקות רכות

יישומים רבים לעולם אינם מוחקים נתונים בפועל. הם מסמנים אותם כמחוקים:

UPDATE articles SET deleted_at = NOW() WHERE id = 12345;

מנקודת המבט של ה-API, המשאב נעלם — GET מחזיר 404, הוא נעלם מרשימות. אבל הנתונים נשארים במסד הנתונים, ניתנים לשחזור במידת הצורך.

זה מספק:

• שחזור ממחיקות בשגגה
• מעקב ביקורת המראה מה נמחק ומתי
• עמידה בדרישות תקנות הדורשות שמירת נתונים
• שלמות התייחסויות עבור משאבים המפנים לפריטים שנמחקו

ממשקי API מסוימים חושפים זאת במפורש:

GET /articles?include_deleted=true
POST /articles/12345/restore

מחיקות מותנות

להרס אין לחצן ביטול. בקשות מותנות מספקות בדיקת בטיחות לפני שעוברים את הגבול.

הכותרת If-Match מבטיחה שאתה מוחק את מה שאתה חושב שאתה מוחק:

DELETE /articles/12345 HTTP/1.1
If-Match: "etag-abc123"

אם המאמר שונה מאז שקראת אותו לאחרונה — אם מישהו ערך אותו בזמן שהחלטת למחוק — ה-ETag לא יתאים:

HTTP/1.1 412 Precondition Failed

זה מונע סוג מסוים של אסון: מחיקת משאב המכיל שינויים שמעולם לא ראית.

מחיקות מרובות

מחיקת מספר משאבים בבת אחת היא עוצמתית ומסוכנת. קיימות מספר גישות:

בקשות נפרדות: פשוט, בטוח, כרוך בבקשות רבות.

DELETE /articles/1
DELETE /articles/2
DELETE /articles/3

פרמטרי שאילתה: עוצמתי, מפחיד.

DELETE /articles?status=draft&created_before=2024-01-01

פילטר שגוי עלול למחוק הכל.

נקודת קצה מפורשת למחיקה מרובה: לא RESTful, אבל בטוח.

POST /articles/bulk-delete
{"ids": [1, 2, 3, 4, 5]}

עבור פעולות מרובות, עדיף לבחור בבהירות על פני אלגנטיות. הפירוט הנוסף הוא יתרון.

אבטחה

DELETE דורש הגנה קפדנית:

אימות: לעולם אל תאפשר מחיקות אנונימיות.

הרשאה: ודא שהמשתמש יכול למחוק את המשאב הספציפי הזה. בעלות על משאב אינה בהכרח בעלות על כל המשאבים.

הגנת CSRF: מנע מאתרים זדוניים להערים על דפדפנים לשלוח בקשות DELETE.

הגבלת קצב: חשבון שנפרץ עם גישת DELETE בלתי מוגבלת הוא קטסטרופה.

רישום ביקורת: תעד כל מחיקה עם חותמת זמן, משתמש, ומה נמחק. כשמשהו ישתבש, תזדקק לזה.

התנהגות מדורגת: החלט מה קורה למשאבים תלויים. גם אותם למחוק? להחזיר שגיאה? התשובה משפיעה על שלמות הנתונים.

מחיקה אסינכרונית

מחיקת כמויות גדולות של נתונים לוקחת זמן. במקום לגרום ללקוחות לחכות, אשר את הבקשה ועבד אותה ברקע:

DELETE /users/12345 HTTP/1.1
→
HTTP/1.1 202 Accepted
{
  "status": "pending",
  "job_id": "delete-job-789",
  "status_url": "/jobs/delete-job-789"
}

לקוחות סוקרים את כתובת הסטטוס עד להשלמת המשימה. תבנית זו מתאימה לכל פעולה שנמשכת זמן רב יותר מפסק זמן סביר לבקשה.

תבנית סל המיחזור

יישומים פונים למשתמש משלבים לעיתים קרובות מחיקות רכות עם תקופת חסד:

1. בקשת DELETE מפעילה מחיקה רכה
2. המשאב נראה "מחוק" למשתמשים
3. תקופת חסד של 30 יום לשחזור
4. משימת רקע מוחקת לצמיתות לאחר תקופת החסד

המשתמשים מקבלים את הסיפוק של מחיקה מיידית. צוותי התפעול מקבלים זמן לתקן טעויות.

שאלות נפוצות על שיטת HTTP DELETE

האם DELETE אמור להחזיר 404 או 204 עבור משאב שכבר נמחק?

רוב ממשקי ה-API מחזירים 404 — זה מיידע אותך אם הבקשה שלך אכן שינתה משהו. אבל 204 הוא מוצדק אם אתה רואה DELETE כ"וודא שהמשאב הזה לא קיים" ולא כ"הסר את המשאב הזה". בחר גישה אחת והיה עקבי.

האם בקשות DELETE יכולות לכלול גוף?

מפרט HTTP אינו אוסר על כך, אבל לקוחות ופרוקסי רבים אינם מטפלים בזה היטב. אם אתה צריך לשלוח נתונים עם DELETE — כמו רשימת מזהים למחיקה מרובה — השתמש בנקודת קצה POST במקום. פחות RESTful, יותר אמין.

מתי כדאי להשתמש במחיקות רכות לעומת מחיקות קשות?

מחיקות רכות לנתוני משתמש שבהם מחיקה בשגגה היא יקרה. מחיקות קשות לנתונים ארעיים כמו אסימוני סשן, וכאשר תקנות דורשות הסרה בפועל (כמו זכות המחיקה של GDPR).

כיצד מטפלים במחיקות מדורגות?

שלוש אפשרויות: מחיקת משאבים תלויים אוטומטית (נוח אבל מפתיע), החזרת 409 Conflict עד שהתלויות יוסרו (בטוח אבל דורש מספר בקשות), או סימון משאבים תלויים כיתומים (שומר על הנתונים אבל צריך ניקוי). תעד את הבחירה שלך בבירור.