204 ללא תוכן

מה אומרים כשאין מה לומר?

לא אומרים כלום. זה 204.

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

צורת השתיקה

תגובת 204 היא ענייה באופן מרשים:

HTTP/1.1 204 No Content
Date: Wed, 21 Oct 2024 07:28:00 GMT

ללא Content-Type. ללא Content-Length. ללא גוף הודעה. הכותרות מסתיימות, וזהו. התגובה שלמה.

זו אינה ריקנות במקרה. זו ריקנות בכוונה.

כשהשתיקה היא התשובה הנכונה

מחיקת דברים

השימוש הטבעי ביותר של 204:

DELETE /api/users/123 HTTP/1.1

HTTP/1.1 204 No Content

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

204 הוא התשובה הכנה היחידה: המשימה בוצעה, ואין עוד מה לומר.

עדכונים ללא הד

כשאתה מעדכן משאב אך אינך צריך שהשרת יחזיר לך אותו:

PUT /api/users/123 HTTP/1.1
Content-Type: application/json

{"name": "Alice Updated", "email": "alice@example.com"}

HTTP/1.1 204 No Content

סיפרת לשרת את המצב החדש. השרת קיבל אותו. למה יחזור על מה שאמרת? אם אתה צריך לאשר את העדכון, שלח בקשת GET. אבל לעתים קרובות, אתה בוטח בהודעה שלך.

פעולות שפשוט מתרחשות

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

POST /api/cache/clear HTTP/1.1

HTTP/1.1 204 No Content

POST /api/users/123/reset-password HTTP/1.1

HTTP/1.1 204 No Content

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

204 לעומת שכניו

200 OK: "הנה הדבר שביקשת." השתמש ב-200 כשיש לך תוכן להחזיר.

201 Created: "יצרתי דבר חדש, והנה היכן למצוא אותו." השתמש ב-201 בעת יצירת משאבים.

202 Accepted: "אעשה זאת מאוחר יותר." השתמש ב-202 כשהעיבוד נדחה.

204 No Content: "בוצע. אין עוד מה לומר." השתמש ב-204 כשהפעולה הצליחה והשתיקה היא התגובה המתאימה.

ההבחנה בין 200 ל-204 חשובה ליעילות. תגובת 200 עם {"success": true} מבזבזת בתים. הלקוח צריך לנתח JSON רק כדי ללמוד מה שקוד הסטטוס כבר אמר לו. 204 מבטל את הבזבוז הזה — אין גוף להעביר, אין JSON לנתח.

כלל "אין גוף"

תגובות 204 חייבות שלא להכיל גוף הודעה. זו אינה המלצה — זהו המפרט. התגובה מסתיימת אחרי הכותרות:

HTTP/1.1 204 No Content
Date: Wed, 21 Oct 2024 07:28:00 GMT

לא עוקב כלום. חלק מספריות HTTP ימתינו לתוכן שלעולם לא יגיע אם הן לא מטפלות ב-204 כראוי, מה שגורם לחרוג מזמן ההמתנה. הריקנות היא מכוונת.

כותרות שאין לכלול:

• Content-Type: אין תוכן פירושו אין סוג תוכן
• Content-Length: השמט אותה, או הגדר ל-0
• Transfer-Encoding: אין מה לקודד

כותרות שניתן לכלול:

• Date: מתי התגובה נוצרה
• Cache-Control: הנחיות מטמון
• כותרות מותאמות אישית: מזהי בקשות, מגבלות קצב, וכדומה

התנהגות דפדפן מוזרה

כשדפדפנים מקבלים 204, קורה משהו מעניין: כלום.

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

<form action="/api/update" method="POST">
    <input type="text" name="value">
    <button type="submit">Update</button>
</form>

אם /api/update מחזיר 204, לחיצה על "שלח" אינה גורמת לשום דבר גלוי. זה יכול להיות שימושי (שמירות ברקע) או מבלבל (משתמשים תוהים אם זה פעל). עצב בהתאם.

קוד לקוח שלא נשבר

הטעות הנפוצה היא לנסות לנתח גוף שאינו קיים:

// זה ייכשל
const response = await fetch('/api/users/123', { method: 'DELETE' });
const data = await response.json(); // שגיאה! אין תוכן לניתוח

בדוק אם הסטטוס הוא 204 לפני הניתוח:

const response = await fetch('/api/users/123', { method: 'DELETE' });

if (response.status === 204) {
    // הצלחה, אין מה לנתח
    return { success: true };
}

if (response.ok) {
    // הצלחה עם תוכן
    return await response.json();
}

throw new Error(`Request failed: ${response.status}`);

או בצורה זהירה יותר:

async function request(url, options) {
    const response = await fetch(url, options);
    
    if (!response.ok) {
        throw new Error(`Request failed: ${response.status}`);
    }
    
    if (response.status === 204) {
        return null;
    }
    
    const contentType = response.headers.get('Content-Type');
    if (contentType?.includes('application/json')) {
        return await response.json();
    }
    
    return await response.text();
}

מתי לא להשתמש ב-204

כשלקוחות מצפים לתוכן: אם צרכני ה-API שלך צריכים את המשאב המעודכן בחזרה, החזר 200 עם המשאב. אל תגרום להם לנחש או לשלוח בקשה שנייה.

בעת יצירת משאבים: יצירת משאב צריכה להחזיר 201 עם מיקום המשאב החדש (ולעתים קרובות גם את תוכנו). 204 אחרי POST שיוצר משהו מבלבל.

לשגיאות: לעולם אל תשתמש ב-204 לשגיאות. אם DELETE מכוון למשאב שלא קיים, החזר 404. אם משהו השתבש, החזר את קוד 4xx או 5xx המתאים עם גוף שגיאה. 204 פירושו הצלחה.

האלגנטיות של כלום

204 מגלם עיקרון: אל תאמר יותר ממה שנחוץ.

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

בפעם הבאה שאתה מתכנן נקודת קצה ב-API ותוהה מה להחזיר, שאל את עצמך: האם יש באמת משהו לומר? אם התשובה היא לא, 204 הוא גם התשובה שלך.

שאלות נפוצות על 204 No Content

האם DELETE צריך להחזיר 204 או 200?

204 הוא הבחירה הנפוצה יותר והנכונה יותר מבחינה סמנטית. לאחר מחיקה, המשאב כבר לא קיים — להחזיר אותו יהיה סותר. API-ים מסוימים מחזירים 200 עם מטא-נתונים על המחיקה, אבל 204 נקי יותר: המשאב נעלם, אין מה לומר.

מה קורה אם בטעות כוללים גוף בתגובת 204?

רוב הלקוחות יתעלמו ממנו, אבל אתה מפר את מפרט HTTP. חלק מהלקוחות עשויים להתנהג באופן בלתי צפוי. אם אתה צריך להחזיר תוכן, השתמש ב-200 במקום.

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

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

האם אפשר להשתמש ב-204 לבקשות GET?

מבחינה טכנית כן, אבל זה יוצא דופן. בקשות GET בדרך כלל מצפות לתוכן. 204 על GET עשוי להצביע על אוסף ריק, אבל 200 עם מערך ריק ([]) בדרך כלל ברור יותר.