עודכן לפני חודש
כשהדפדפן שלך שואל "האם אתה בטוח שברצונך לשלוח טופס זה מחדש?" הוא לא מציק לך. הוא שואל מפני שהבקשה המקורית לא הבטיחה מה יקרה אם תעשה זאת פעמיים. אולי תחויב שוב על כרטיס האשראי. אולי תיצור הזמנה כפולה. הדפדפן פשוט לא יודע — וחוסר הוודאות הזה מובנה בשיטת ה-HTTP שנבחרה.
שיטות HTTP הן הבטחות על השלכות. הן חוזים בין לקוח לשרת על מה שיקרה כאשר תתבצע בקשה. GET מבטיחה רק להסתכל. POST מזהירה שמשהו ישתנה. כל הארכיטקטורה של הרשת — שמירה במטמון, ניסיונות חוזרים, טעינה מוקדמת, אזהרת הרענון — תלויה בכך שהבטחות אלו יקוימו.
ההבטחה של GET
GET אומרת: "אני רק אסתכל. שום דבר לא ישתנה בגלל הבקשה הזו."
כשאתה מקליד כתובת URL או לוחץ על קישור, הדפדפן שלך שולח בקשת GET. השרת מחזיר נתונים — דף אינטרנט, תמונה, JSON — מבלי לשנות דבר. ההבטחה הזו היא מה שהופך את הרשת למהירה ואמינה:
- שמירה במטמון עובדת — כי התגובה לא תשתנה אם תשאל שוב
- טעינה מוקדמת עובדת — כי טעינת קישור מראש לא תפעיל פעולות לא רצויות
- סימניות עובדות — כי ה-URL מכיל את כל מה שדרוש לחזרה על הבקשה
- כפתור החזרה עובד — כי ביקור חוזר לא ישלח שוב משהו בטעות
בקשות GET יכולות לכלול פרמטרים ב-URL (?search=query&page=2), אך פרמטרים אלו צריכים רק לסנן או לפרט מה מעניין אותך — לעולם לא להפעיל שינויים.
הפרה של ההבטחה הזו — ביצוע בקשת GET שמשנה נתונים — היא אחת הטעויות המסוכנות ביותר בפיתוח אתרים. סורק האינטרנט של Google הוביל פעם חברה לפשיטת רגל כשעקב אחר קישורי "מחק" שיושמו כבקשות GET.
האזהרה של POST
POST אומרת: "משהו ישתנה. אני לא מבטיח מה יקרה אם תעשה זאת פעמיים."
כשאתה שולח טופס, מעלה קובץ, או יוצר חשבון, אתה מבצע בקשת POST. הנתונים נשלחים בגוף הבקשה (לא ב-URL), והשרת בדרך כלל יוצר משהו, מעבד משהו, או מפעיל פעולה מסוימת.
POST לא מבטיחה דבר לגבי חזרה על הפעולה. שלח טופס תשלום פעמיים? ייתכן שתחויב פעמיים. צור חשבון פעמיים? ייתכן שתקבל רשומות כפולות. זו הסיבה לכך ש:
- דפדפנים מזהירים לפני רענון תוצאות POST
- כפתור החזרה מרגיש מסוכן אחרי תהליך רכישה
- לקוחות API זקוקים ללוגיקת ניסיון חוזר מפורשת עבור בקשות POST
POST היא השיטה הכנה. היא מודה שלפעולות יש השלכות — ואולי הן אינן הפיכות ואולי אינן ניתנות לחזרה.
PUT: ההחלפה המלאה
PUT אומרת: "הנה בדיוק מה שמשאב זה אמור להיות. החלף הכל."
בשונה מ-POST שיוצרת או מפעילה, PUT מחליפה. אתה לא מבקש מהשרת להבין מה השתנה — אתה מוסר לו את המצב החדש המלא. כשמעדכנים פרופיל משתמש עם PUT, שולחים כל שדה — גם שלא השתנו.
ל-PUT יש ערובה חזקה: עשות זאת פעם אחת זהה לעשות זאת פעמיים. אם הבקשה הראשונה הצליחה, הבקשה השנייה רק מאשרת את אותו מצב. אם הבקשה הראשונה נכשלה מסיבה לא ברורה, ניתן לנסות שוב בבטחה. תכונה זו — אידמפוטנטיות — הופכת את PUT לחיונית במערכות אמינות.
PATCH: העדכון החלקי
PATCH אומרת: "שנה רק את הדברים הספציפיים האלה."
בעוד ש-PUT שולחת את המשאב כולו, PATCH שולחת רק את השינויים. עדכן כתובת דוא"ל בלבד מבלי לגעת בשם, בטלפון או בהעדפות. זה יעיל עבור משאבים גדולים ומעשי כשאין ללקוח גישה לכל השדות.
ההבטחה של PATCH חלשה יותר מזו של PUT. האם חזרה על PATCH בטוחה — זה תלוי מה ה-patch אומר. "הגדר דוא"ל ל-X" בטוח לחזור עליו. "הגדל מונה ב-1" — לא. השיטה עצמה אינה מבטיחה דבר בעניין.
DELETE: ההסרה
DELETE אומרת: "הסר את המשאב הזה."
DELETE ל-/api/users/123 מסיר את המשתמש הזה. בקשות GET שיגיעו לאחר מכן יקבלו 404 Not Found. פשוט ובהיר.
כמו PUT, גם DELETE אידמפוטנטית. מחק משהו פעמיים? הוא עדיין נמחק. זה הופך את DELETE לבטוחה לניסיון חוזר כאשר שגיאות רשת משאירות ספק לגבי הצלחת הבקשה הראשונה.
מערכות רבות מיישמות "מחיקות רכות" — המשאב מסומן כנמחק במקום להיות מושמד ממש, שומר נתונים לצורך שחזור או ביקורת — אך מנקודת מבט הלקוח, המשאב נעלם.
HEAD ו-OPTIONS: שיטות המטא-נתונים
HEAD אומרת: "ספר לי על המשאב הזה מבלי לשלוח אותו."
HEAD היא GET ללא הגוף. בדוק אם קובץ קיים, ראה מתי שונה לאחרונה, גלה כמה הוא גדול — הכל מבלי להוריד. מערכות ניטור משתמשות ב-HEAD כדי לוודא שהשרתים מגיבים מבלי להעביר דפים מלאים.
OPTIONS אומרת: "מה אפשר לעשות כאן?"
OPTIONS שואלת את השרת אילו שיטות מותרות. דפדפנים שולחים OPTIONS אוטומטית כבדיקות "preflight" לפני בקשות מסוימות חוצות-מקורות — מבקשים אישור לפני ביצוע הבקשה האמיתית.
שיטות בטוחות: ההבטחה לא לשנות דבר
GET, HEAD, ו-OPTIONS הן שיטות בטוחות. הן מבטיחות שלא לשנות את מצב השרת. הבטחה זו מאפשרת:
- שמירה אגרסיבית במטמון על ידי proxy-ים ו-CDN-ים
- טעינה מוקדמת על ידי דפדפנים שמנחשים מה תלחץ הבא
- סורקי אינטרנט שחוקרים את האתר שלך ללא חשש
- לוגיקת ניסיון חוזר ללא דאגה לכפילויות
POST, PUT, PATCH, ו-DELETE הן שיטות לא בטוחות. הן עלולות לשנות דברים. שרתים צריכים לאמת אותן בקפידה. לקוחות לא צריכים לחזור עליהן בקלות ראש.
שיטות אידמפוטנטיות: ההבטחה לגבי חזרה
GET, HEAD, OPTIONS, PUT, ו-DELETE הן אידמפוטנטיות. פעם אחת זהה לפעמיים. הבטחה זו מאפשרת:
- ניסיונות חוזרים אוטומטיים כשמתרחשות שגיאות רשת
- מאזני עומסים שיכולים לשלוח מחדש בקשות לשרתים תקינים
- לקוחות שאינם צריכים לעקוב אחר הצלחת הבקשה
POST היא במפורש לא אידמפוטנטית. השיטה עצמה מזהירה: "אני לא יכולה להבטיח מה יקרה פעמיים." PATCH היא טכנית לא-אידמפוטנטית, אם כי יישומים רבים מתכננים את ה-patch-ים שלהם כבטוחים לחזרה.
מוסכמות RESTful: שיטות כשפה
ממשקי REST API משתמשים בשיטות HTTP כדי ליצור ממשקים צפויים:
| פעולה | שיטה | URL | משמעות |
|---|---|---|---|
| רשימה | GET | /users | הצג את כל המשתמשים |
| קריאה | GET | /users/123 | הצג משתמש זה |
| יצירה | POST | /users | צור משתמש חדש |
| החלפה | PUT | /users/123 | החלף משתמש זה לחלוטין |
| עדכון | PATCH | /users/123 | שנה משתמש זה חלקית |
| מחיקה | DELETE | /users/123 | הסר משתמש זה |
ברגע שמבינים את הדפוס הזה, ממשקי API הופכים לתיעוד עצמי. השיטה אומרת לך מה סוג הפעולה. ה-URL אומר לך על איזה משאב. השילוב — מה בדיוק יקרה.
החוזים שמחזיקים את הרשת ביחד
שיטות HTTP אינן תוויות שרירותיות. הן הבטחות שכל הרשת מסתמכת עליהן.
ההבטחה של GET לרק להסתכל היא הסיבה שבגללה שמירה במטמון עובדת, טעינה מוקדמת בטוחה, וכפתור החזרה לא ישלח את ההזמנה שלך מחדש בטעות. האזהרה הכנה של POST על השלכות היא הסיבה שדפדפנים מפסיקים אותך לפני רענון דף תשלום. האידמפוטנטיות של PUT ו-DELETE היא הסיבה שמערכות מבוזרות יכולות לנסות שוב בקשות שנכשלו ללא חשש.
כשהבטחות אלו מקוימות, הרשת עובדת בצורה חלקה. כשהן מופרות — כאשר GET מוחקת משהו, כאשר מניחים ש-POST בטוחה לחזרה — דברים נשברים בדרכים שקשה לאבחן ולעיתים בלתי אפשרי לתקן.
השיטות פשוטות. ההבטחות שהן מקודדות — הן מה שחשוב.
שאלות נפוצות על שיטות HTTP
מדוע דפדפנים משתמשים רק ב-GET וב-POST בטפסים, ולא ב-PUT או DELETE?
טפסי HTML תוכננו לפני שמוסכמות REST הפכו לנפוצות. אלמנט הטופס תומך רק ב-GET וב-POST כערכי שיטה. יישומי אינטרנט מודרניים עוקפים זאת באמצעות JavaScript לשליחת בקשות PUT, PATCH ו-DELETE דרך fetch או XMLHttpRequest, או על ידי הכללת שדה נסתר כמו _method=DELETE שהשרת מפרש.
האם בקשת GET יכולה לכלול גוף?
מבחינה טכנית — כן, אבל זה רעיון רע. מפרט ה-HTTP אינו אוסר זאת, אך הוא גם קובע שהשרתים רשאים להתעלם מגופי בקשות GET. proxy-ים, מטמונים וכלים רבים מסירים אותם או מטפלים בהם בצורה שגויה. אם צריך לשלוח נתונים מורכבים, עדיף להשתמש ב-POST עם אינדיקציה ברורה שמדובר בשאילתה ולא בשינוי.
מה ההבדל בין 200 OK ל-204 No Content עבור DELETE?
שניהם מציינים הצלחה. 200 OK בדרך כלל כולל גוף תגובה — אולי המצב הסופי של המשאב שנמחק, או הודעת אישור. 204 No Content אומר "הצלחה, ואין מה להוסיף" — ללא גוף כלל. עבור DELETE, 204 נפוץ יותר כיוון שלרוב אין מה להחזיר על משהו שכבר לא קיים.
כיצד הופכים POST לאידמפוטנטית?
משתמשים במפתחות אידמפוטנטיים. הלקוח מייצר מפתח ייחודי לכל פעולה מיועדת ושולח אותו עם הבקשה. השרת עוקב אחר המפתחות שראה — אם הגיעה בקשה עם מפתח שכבר עובד, השרת מחזיר את התגובה המקורית במקום לעבד מחדש. Stripe וממשקי API של תשלומים אחרים משתמשים בדפוס זה.
האם דף זה היה מועיל?