מה זה הגבלת קצב ב-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 שנשאר חי ובר השגה. התפקיד של אינטגרציה טובה הוא לחיות בנוחות בתוך המגבלה, לא לנסות לעקוף אותה.

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

כשאתה חוצה את הקו, ה-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 בשפה פשוטה.

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

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

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