שיטת ה-POST של HTTP

GET היא שאלה. POST היא פעולה.

זה ההבדל כולו. כשאתה לוחץ על קישור, הדפדפן שלך שואל "מה יש בכתובת URL הזו?" כשאתה שולח טופס, הדפדפן שלך אומר "הנה נתונים — עשה עם זה משהו." כל התחברות, כל העלאת קובץ, כל תשלום, כל קריאת API שיוצרת או משנה משהו: POST.

מה POST עושה

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

פעולות POST נפוצות:

• שליחת טפסי התחברות והרשמה
• יצירת משאבים חדשים (פוסטים, הזמנות, חשבונות)
• העלאת קבצים
• שליחת נתונים ל-APIs
• עיבוד תשלומים

המילה המפתח היא עיבוד. GET מאחזר את מה שקיים. POST גורם למשהו לקרות.

מבנה בקשת POST

לבקשת POST יש שלושה חלקים:

שורת הבקשה:

POST /api/users HTTP/1.1

כותרות:

Host: example.com
Content-Type: application/json
Content-Length: 87

גוף הבקשה:

{
  "username": "johndoe",
  "email": "john@example.com",
  "password": "securepass123"
}

הגוף הוא המקום שבו POST נושא את המטען שלו. בשונה מ-GET, שדוחס פרמטרים לתוך ה-URL, POST מעביר את הנתונים בגוף — מה שמאפשר מטענים גדולים יותר ומונע חשיפת מידע רגיש ב-URLs, ביומנים ובהיסטוריית הדפדפן.

סוגי תוכן

הכותרת Content-Type אומרת לשרת כיצד לפרש את הגוף.

application/x-www-form-urlencoded — ברירת המחדל לטפסי HTML:

username=johndoe&email=john%40example.com&password=securepass123

multipart/form-data — נדרש להעלאת קבצים:

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="username"

johndoe
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: image/jpeg

[binary image data]
------WebKitFormBoundary7MA4YWxkTrZu0gW--

application/json — הסטנדרט עבור APIs מודרניים:

{
  "username": "johndoe",
  "preferences": {
    "theme": "dark",
    "notifications": true
  }
}

POST מול GET

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

מתי להשתמש ב-POST

השתמש ב-POST כאשר:

• יוצרים, מעדכנים או מוחקים משאבים
• מטפלים בנתונים רגישים (סיסמאות, פרטי תשלום)
• שולחים מטענים גדולים או קבצים
• מדובר בפעולות שלא אמורות להתבצע בטעות שוב

אל תשתמש ב-POST כאשר:

• רק מאחזרים נתונים (השתמש ב-GET)
• רוצים שה-URLs יהיו ניתנים לשיתוף או לסימניה
• הפעולה בטוחה לחזרה

שליחת טפסים

<form method="POST" action="/register">
  <input type="text" name="username" />
  <input type="email" name="email" />
  <input type="password" name="password" />
  <button type="submit">Register</button>
</form>

כשנשלח, הדפדפן שולח:

POST /register HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=johndoe&email=john%40example.com&password=securepass123

להעלאת קבצים, הוסף enctype="multipart/form-data" לתג הטופס.

POST ב-APIs

fetch('https://api.example.com/articles', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer token123'
  },
  body: JSON.stringify({
    title: 'Understanding HTTP POST',
    content: 'POST is used to submit data...',
    tags: ['http', 'tutorial']
  })
});

יצירה מוצלחת מחזירה:

HTTP/1.1 201 Created
Location: /articles/12345

{
  "id": 12345,
  "title": "Understanding HTTP POST",
  "created_at": "2024-05-15T10:30:00Z"
}

הסטטוס 201 Created מאשר שהמשאב קיים. הכותרת Location אומרת לך היכן למצוא אותו.

קודי תגובה

בעיית השליחה הכפולה

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

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

פתרונות:

Post-Redirect-Get: לאחר POST מוצלח, בצע הפניה ל-GET:

POST /create-order → 303 See Other → GET /order/12345

עכשיו אם משתמשים מרעננים, הם מרעננים את ה-GET הבטוח, לא את ה-POST המסוכן.

מפתחות אידמפוטנטיות: הלקוח מייצר מזהה ייחודי לכל שליחה:

fetch('/api/orders', {
  method: 'POST',
  headers: { 'Idempotency-Key': 'unique-key-12345' },
  body: JSON.stringify(orderData)
});

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

אסימוני CSRF: הטמע אסימונים חד-פעמיים בטפסים. כל שליחה מבטלת את האסימון שלה.

אבטחה

השתמש ב-HTTPS: נתוני POST אינם ב-URL, אבל הם עדיין טקסט רגיל מעל HTTP. הצפן את החיבור.

הגן מפני CSRF: Cross-Site Request Forgery מרמה דפדפנים לשלוח בקשות POST לא מורשות. השתמש באסימוני CSRF, עוגיות SameSite, ואימות כותרות Origin/Referer.

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

הגבל קצב: מנע ניצול לרעה על ידי הגבלת תדירות ה-POST.

הגבל גודל גוף: מנע מיצוי זיכרון ממטענים גדולים מדי.

נקודות עיקריות

• POST שולח נתונים הגורמים לשינויים בצד השרת — זו פעולה, לא שאלה
• הנתונים מועברים בגוף הבקשה, מה שמונע את חשיפתם ב-URLs, ביומנים ובהיסטוריית הדפדפן
• POST אינו אידמפוטנטי: לאותה בקשה יכולות להיות תוצאות שונות בכל פעם
• השתמש ב-Post-Redirect-Get ובמפתחות אידמפוטנטיות כדי למנוע שליחות כפולות
• תמיד השתמש ב-HTTPS ובהגנת CSRF עבור נקודות קצה של POST המטפלות בנתונים רגישים

שאלות נפוצות על שיטת ה-POST של HTTP

האם ניתן לשמור תגובות POST במטמון?

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

מדוע רענון עמוד לפעמים מזהיר על שליחה חוזרת של נתונים?

כשמרעננים עמוד שנטען דרך POST, הדפדפן יצטרך לשלוח שוב את בקשת ה-POST. מכיוון ש-POST יכול לגרום לתופעות לוואי (כמו חיוב כרטיס פעמיים), הדפדפנים מזהירים אותך. זו הסיבה שדפוס ה-Post-Redirect-Get קיים — הוא מחליף את ה-POST בהיסטוריה ב-GET בטוח.

האם POST מאובטח יותר מ-GET?

POST שומר נתונים מחוץ ל-URLs, מה שאומר שהם לא יופיעו בהיסטוריית הדפדפן, ביומני שרת או בסימניות. אבל נתוני POST עדיין נשלחים כטקסט רגיל מעל HTTP. אבטחה אמיתית מגיעה מ-HTTPS, שמצפין את כל הבקשה ללא קשר לשיטה.

מתי כדאי להשתמש ב-PUT במקום ב-POST?

POST יוצר משאבים חדשים כשאינך יודע את ה-URL הסופי (POST /articles יוצר מאמר חדש איפשהו). PUT מחליף משאב ב-URL ידוע (PUT /articles/123 מחליף את המאמר 123). PUT הוא אידמפוטנטי — שליחתו פעמיים זהה לשליחתו פעם אחת. POST אינו.