200 OK

כשאתה לוחץ על קישור ודף נטען, כשאתה שולח טופס ומקבל אישור, כשממשק API מחזיר את הנתונים שביקשת — מאחורי כמעט כל אינטראקציה מוצלחת מסתתרת תגובת 200 OK. זהו קוד הסטטוס הנפוץ ביותר ב-HTTP, הדרך שבה האינטרנט אומר "כן, והנה זה."

מה 200 OK באמת אומר

200 OK מאותת על ארבעה דברים:

1. הבקשה הגיעה והובנה
2. הבקשה הייתה תקינה
3. השרת עיבד אותה בהצלחה
4. התגובה מכילה את מה שביקשת

HTTP/1.1 200 OK
Content-Type: application/json

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

זהו. בקשה הובנה, עובדה, הנה הנתונים שלך.

מתי 200 הוא הבחירה הנכונה

בקשות GET שמחזירות נתונים:

GET /api/users/123

HTTP/1.1 200 OK
{"id": 123, "name": "Alice"}

בקשות PUT/PATCH שמעדכנות משאבים:

PUT /api/users/123
{"name": "Alice Smith"}

HTTP/1.1 200 OK
{"id": 123, "name": "Alice Smith"}

בקשות DELETE כשרוצים לאשר מה נמחק:

DELETE /api/users/123

HTTP/1.1 200 OK
{"message": "User deleted", "id": 123}

בקשות POST שמעבדות נתונים אבל לא יוצרות משאבים חדשים:

POST /api/calculate
{"expression": "2 + 2"}

HTTP/1.1 200 OK
{"result": 4}

מתי 200 הוא הבחירה הלא נכונה

למשפחת 2xx יש קודים ספציפיים יותר. להשתמש ב-200 כשקוד אחר במשפחה מתאים יותר זה כמו לענות על כל שאלה עם "בסדר" — טכנית לא טועים, אבל מפספסים הזדמנות לתקשר.

יצרת משהו חדש? השתמש ב-201

POST /api/users
{"name": "Bob"}

HTTP/1.1 201 Created
Location: /api/users/124

{"id": 124, "name": "Bob"}

201 אומר "לא רק שזה עבד, עכשיו קיים משהו חדש." הכותרת Location אומרת לך איפה למצוא אותו.

אין מה להחזיר? השתמש ב-204

DELETE /api/users/123

HTTP/1.1 204 No Content

אין גוף. אין Content-Length. רק שתיקה שמשמעותה הצלחה. זה נקי יותר מהחזרת {"success": true} עם 200.

מעבד מאוחר יותר? השתמש ב-202

POST /api/video/render
{"source": "video.raw"}

HTTP/1.1 202 Accepted

{"jobId": "abc123", "status": "queued"}

202 אומר "קיבלתי, עובד על זה, עדיין לא גמרתי." הלקוח יודע לבדוק שוב מאוחר יותר.

המלכודת: הצלחת HTTP מול הצלחה עסקית

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

חלק מממשקי ה-API עושים את זה:

POST /api/transfer
{"amount": 1000, "to": "account-456"}

HTTP/1.1 200 OK

{"success": false, "error": "Insufficient funds"}

בקשת ה-HTTP הצליחה. ההעברה נכשלה. קוד הסטטוס אומר דבר אחד, הגוף אומר דבר אחר.

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

עדיף:

HTTP/1.1 400 Bad Request

{"error": "Insufficient funds", "code": "INSUFFICIENT_FUNDS"}

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

מה נכנס לגוף התגובה

תגובת 200 צריכה להכיל משהו שימושי. לא רק {"success": true} — זה מבזבז את ההזדמנות.

עבור GET, החזר את המשאב:

{
    "id": 123,
    "name": "Alice",
    "email": "alice@example.com",
    "createdAt": "2024-01-15T10:30:00Z"
}

עבור בקשת עדכון, החזר את התוצאה:

{
    "id": 124,
    "name": "Bob",
    "createdAt": "2024-10-21T14:22:00Z"
}

הלקוח ביקש שמשהו יקרה. הראה לו מה קרה.

Content-Type מספר את הסיפור

200 OK יכול לשאת כל דבר:

Content-Type: application/json    → תגובת API
Content-Type: text/html           → דף אינטרנט
Content-Type: image/png           → תמונה
Content-Type: application/pdf     → מסמך

כותרת ה-Content-Type היא הדרך שבה הלקוח יודע מה הוא קיבל. היעדרה מכריח לקוחות לנחש — וניחושים מובילים לבאגים.

התנהגות מטמון

תגובות 200 ניתנות לשמירה במטמון כברירת מחדל. דפדפנים, CDNs ופרוקסי עשויים לאחסן אותן:

HTTP/1.1 200 OK
Cache-Control: public, max-age=3600

{"data": "cacheable for one hour"}

עבור נתונים רגישים, מנע שמירה במטמון:

HTTP/1.1 200 OK
Cache-Control: no-store

{"data": "never cache this"}

טעויות נפוצות

החזרת 200 עבור כשלונות. אם משהו השתבש, אמור זאת עם 4xx או 5xx.

שימוש ב-200 כשמתאים 204. גוף ריק עם 200 מבלבל. השתמש ב-204.

שימוש ב-200 כשמתאים 201. יצרת משאב? ספר ללקוח עם 201 וכותרת Location.

כותרת Content-Type חסרה. לקוחות צריכים לדעת מה שלחת להם.

גוף תגובה ריק מתוכן. {"success": true} לא אומר ללקוח שום דבר שימושי. החזר נתונים אמיתיים.

המבחן הפשוט

כשמחליטים בין 200 לקודים האחרים במשפחה, שאל:

• יצרתי משהו חדש? ← 201
• אין מה להחזיר? ← 204
• עדיין מעבד? ← 202
• יש תוכן להחזיר? ← 200
• משהו נכשל? ← 4xx או 5xx

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

שאלות נפוצות על 200 OK

האם תגובת 200 יכולה לכלול גוף ריק?

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

האם להחזיר 200 או 201 כשיוצרים משאב?

201 Created מדויק יותר ומבהיר את הכוונה טוב יותר. הוא גם נהוג לכלול כותרת Location שמצביעה על המשאב החדש. השתמש ב-201 ליצירה, ב-200 לכל השאר שמחזיר תוכן.

למה חלק מממשקי ה-API מחזירים 200 עבור שגיאות?

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

מה ההבדל בין 200 ל-202?

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