מה זה הגבלת קצב ב-API במילים פשוטות?

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

למה ל-APIs יש מגבלות קצב?

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

איך נראה מצב של חריגה ממגבלת קצב?

מבחינה טכנית, ה-API מחזיר לרוב סטטוס HTTP 429 (יותר מדי בקשות), לעתים עם כותרת Retry-After שאומרת כמה זמן לחכות. מהצד העסקי זה נראה כמו פיצ'ר שעובד רוב הזמן אבל נשבר בשעות עמוסות, ייבוא שעוצר באמצע, או סנכרון ששומט רשומות בשקט. הכשלים התלויים בעומס האלה הם סימן קלאסי.

איך מטפלים במגבלות קצב של API?

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

מה זה השהיה מעריכית?

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

מה זה הגבלת קצב ב-API (ולמה זה חשוב)?

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

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

אז מה זה הגבלת קצב ב-API באמת?

API הוא הדלת שמערכת אחת פותחת כדי שאחרת תוכל לבקש ממנה נתונים. הגבלת קצב היא הסדרן שעומד בדלת הזו וסופר את הקצב שבו נכנסים ויוצאים. בעל ה-API קובע את הכללים: אולי 60 בקשות בדקה, אולי 10,000 ביום, אולי שניהם יחד. שולחים בקשות לאט מזה ולעולם לא שמים לב שהסדרן קיים. שולחים מהר יותר - נדחים עד שהמונה מתאפס.

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

למה API מגביל את מספר הקריאות

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

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

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

איך נראה מצב של חריגה ממגבלה

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

סימן	משמעות בשפה פשוטה
429 Too Many Requests	שלחתם יותר מדי קריאות. עצרו וחכו לפני שמנסים שוב.
Retry-After: 30	השרת אומר בדיוק כמה שניות לחכות לפני ניסיון חוזר.
X-RateLimit-Limit	מספר הבקשות הכולל המותר בחלון הנוכחי.
X-RateLimit-Remaining	כמה בקשות נותרו לפני שנחסמים.
X-RateLimit-Reset	מתי התקציב מתמלא מחדש - לרוב חותמת זמן.

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

סוגי חלונות ששווה להכיר

לא כל המגבלות סופרות באותו אופן. חלון קבוע מתאפס לפי השעון, נניח בתחילת כל דקה, כך שצרור בקשות ממש לפני ואחרי האיפוס יכול להכפיל לרגע את הקצב. חלון מתגלגל מסתכל תמיד על 60 השניות האחרונות - מה שמחמיר וחלק יותר. דלי אסימונים מקצה כמות קטנה שאפשר לבזבז בצרור, ואז מתמלאת בהתמדה. לא צריך לשנן את אלה - רק לדעת ש"100 בדקה" יכול להתנהג אחרת בהתאם לסגנון שהספק בחר, ולכן בדיקה מול ה-API האמיתי היא חיונית.

איך מטפלים במגבלות קצב נכון

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

1. מטמון - כדי שמפסיקים לשאול את אותה שאלה

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

2. ניסיון חוזר עם השהיה מתגברת

כשמקבלים 429, המהלך השגוי הוא לנסות שוב מיד - כי זה רק מוסיף לערימה. המהלך הנכון הוא השהיה מעריכית (exponential backoff): לחכות שנייה, ואז שתיים, ואז ארבע, ואז שמונה - ולהיות סבלניים יותר בכל פעם, רצוי עם קצת אקראיות כדי שלא כל הקליינטים ינסו שוב בו זמנית. אם התגובה כללה ערך Retry-After, עדיף לכבד אותו בדיוק. כשזה נעשה היטב, המשתמש לא רואה את התקלה - הבקשה פשוט נוחתת רגע מאוחר יותר.

3. תור והסדרת קצב הבקשות

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

4. מעקב אחר התקציב ופיזורו

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

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

האם הגבלת קצב חשובה לעסק שלכם?

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

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