GET: אחזור משאבים

כאשר אתם מקלידים כתובת URL ולוחצים על Enter, אתם שואלים שאלה. זה כל מה שבקשת GET היא — שאלה המופנית לשרת, שמבקשת ממנו להראות לכם משהו. השרת עונה, אתם מקבלים את התשובה, ושום דבר לא משתנה.

הפשטות הזו היא מקור הכוח של GET.

השאלה שלא משנה דבר

בקשת GET מאחזרת משאב. היא לא יוצרת, משנה, או מוחקת — היא רק קוראת.

GET /api/users/123 HTTP/1.1
Host: example.com
Accept: application/json

השרת מגיב עם התשובה:

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

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

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

GET היא גם אידמפוטנטית — שאילת אותה שאלה עשר פעמים נותנת לכם את אותה תשובה עשר פעמים. שום דבר לא מצטבר. שום דבר לא משתנה.

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

מדוע בטיחות ואידמפוטנטיות חשובות

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

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

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

עידון השאלה עם פרמטרי שאילתה

נתיב ה-URL מזהה על מה אתם שואלים. פרמטרי שאילתה מעדנים את השאלה:

GET /api/users?role=admin&status=active&page=2 HTTP/1.1

זה שואל: "הראה לי את העמוד השני של משתמשי אדמין פעילים."

פרמטרי שאילתה מטפלים בסינון (status=active), מיון (sort=created_at), עימוד (page=2&limit=50), וחיפוש (q=javascript). הם גלויים ב-URL, מה שהופך אותם למושלמים לסימניות ושיתוף — אך מסוכנים לסודות.

כתובות URL מופיעות בהיסטוריית הדפדפן. הן מופיעות ביומני שרתים. הן דולפות דרך כותרות referrer. לעולם אל תכניסו סיסמאות, מפתחות API, או מספרי כרטיסי אשראי לפרמטרי שאילתה.

יש גם מגבלת אורך. רוב הדפדפנים מגבילים כתובות URL לכ-2,000-8,000 תווים. אם אתם צריכים לשלוח יותר נתונים מכך, אתם זקוקים למתודה אחרת.

מטמון: הפרס

מכיוון שבקשות GET הן צפויות, שרתים יכולים לספר ללקוחות בדיוק כמה זמן לזכור את התשובה:

Cache-Control: max-age=3600

זה אומר: "אתם יכולים לעשות שימוש חוזר בתגובה הזו במשך שעה מבלי לשאול שוב."

עבור משאבים שעלולים להשתנות, שרתים יכולים להשתמש ב-ETags — טביעות אצבע ייחודיות לגרסאות ספציפיות:

ETag: "abc123"

בפעם הבאה שתבקשו את המשאב הזה, תוכלו לשאול: "האם הוא השתנה מאז גרסה abc123?" אם לא, השרת מגיב עם 304 Not Modified — ללא גוף, רוחב פס מינימלי, הכל מהיר יותר.

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

כאשר GET הופך למסוכן

הפרו את החוזה, ודברים מתפרקים בדרכים מפתיעות.

אסון הטעינה המוקדמת: מפתח יוצר קישור כמו /delete-account?user=123 שמוחק בפועל את החשבון כאשר לוחצים עליו. לקוח דואר אלקטרוני טוען מוקדם את הקישור כדי לזרז את הטעינה. החשבון נעלם לפני שהמשתמש אפילו רואה את הדואר האלקטרוני. זה לא היפותטי — זה קרה.

הסוד שדלף: מפתח API נכנס לפרמטר שאילתה לנוחות. הוא מופיע ביומני שרתים, מאונדקס על ידי מנוע חיפוש דרך כותרת referrer, ומסתיים בדוח פרצת אבטחה.

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

הכלל פשוט: אם הפעולה משנה דבר — יוצרת רשומה, מעבדת תשלום, שולחת דואר אלקטרוני, מגדילה מונה — היא לא יכולה להיות בקשת GET. השתמשו ב-POST, PUT, PATCH, או DELETE.

החוזה

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

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

שאלות נפוצות על בקשות GET

מדוע דפדפנים יכולים לטעון מוקדם בקשות GET אך לא בקשות POST?

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

מה קורה אם בקשת ה-GET שלי ארוכה מדי?

השרת ככל הנראה ידחה אותה עם שגיאת 414 URI Too Long. לשרתים ודפדפנים שונים יש מגבלות שונות, אבל להישאר מתחת ל-2,000 תווים הוא בטוח. אם אתם צריכים לשלוח יותר נתונים, השתמשו ב-POST עם הנתונים בגוף הבקשה במקום ב-URL.

האם אני יכול להשתמש ב-GET עבור טופס חיפוש?

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

כיצד אני מונע שמירה במטמון עבור בקשת GET שמחזירה נתונים דינמיים?

הגדירו את כותרת Cache-Control ל-no-store או no-cache. הראשון מונע כל שמירה במטמון; השני מאפשר שמירה במטמון אך דורש אימות מחדש לפני כל שימוש. עבור נתונים דינמיים ביותר כמו מחירי מניות בזמן אמת, no-store מבטיח שכל בקשה הולכת לשרת.