התאמת השימוש ב-CAPTCHA ליתרת סביבת העבודה
התחילו בסביבת העבודה שמפתח ה-API שלה יצר את המשימות. לאחר מכן הבחינו בין שימוש ליתרה: תצוגת 28 הימים האחרונים בקונסולה אינה חשבונית, וטעינת יתרה אינה הוצאה.
בדף הזה
השוו את אותה סביבת עבודה ואת אותה תקופה
בקשות API מאומתות באמצעות מפתח API של סביבת עבודה. בדקו את סביבת העבודה הזו בעת התאמת השימוש; שם מארח משותף של יעד אינו מעיד שהבקשות שייכות לאותה סביבת עבודה.
נתוני השימוש ב-/usage מסומנים כ-28 הימים האחרונים. הם מציגים את Request volume, Successful, Failed (not billed), Average latency, ואחד מהבאים: Period spend או Unlimited coverage. אל תסיקו מחלון הזמן הזה בלבד שקיימת חשבונית תואמת או מהי היתרה הנוכחית.
השתמשו ב-By site profile כדי לאתר זינוק. השוו את Site, Share ו-Requests כדי למצוא היכן הנפח גדל, ואז בדקו את Success ואת Billing. אלה אירועי שימוש בשירות, ולא ראיה לכך שהיעד קיבל את הבקשות שנוצרו בעקבותיהם.
משימה מוכנה מחויבת — גם אם היעד דוחה אותה
משימה בסטטוס ready מחויבת. על פתרון שנכשל ניתן החזר. יצירת משימה או קבלת תגובת HTTP מוצלחת אינן שקולות לקבלת פתרון שמיש; רק ready מכיל פתרון כזה.
אם שירות הפתרון מחזיר פתרון מוכן אך האתר דוחה את הבקשה שנשלחת לאחר מכן, אין מדובר במשימת פתרון שנכשלה. אל תספרו אותה תחת Failed (not billed) ואל תניחו שיינתן עליה החזר אוטומטי. משימה חלופית שמגיעה לסטטוס ready היא פתרון נוסף שמחויב.
הפרידו בין יתרה שנרכשה לבין חיובי שימוש
סכום ההפקדה המינימלי ליתרה הוא $10; יתרת ההצטרפות היא $5. הפקדה מוסיפה יתרה לסביבת העבודה — היא אינה מציינת כמה הוצא במהלך חלון השימוש. יש להפריד בין יתרה שנרכשה ליתרת הצטרפות כשמשווים בין התשלומים ליתרה.
| מוצר | USD לכל 1,000 פתרונות |
|---|---|
| reCAPTCHA | $2.00 |
| Kasada | $1.25 |
| TMPT | $0.99 |
להערכת עלות לפי שימוש, יש להשתמש במשימות מוכנות שחויבו — ולא בנפח הבקשות הכולל. אם במסוף מופיע Unlimited coverage, יש לבדוק את התוכנית החודשית הרלוונטית למוצר במקום לתמחר את כל הבקשות לפי שימוש. גם יתרת החשבון או בונוס רלוונטי עשויים לשנות את סכום היתרה הנוספת הנדרש.
איתור הבקשות הלוגיות שמאחורי זינוק בשימוש
- 1.
התאמת האתר וחלון הזמן הרלוונטיים
השתמשו בפילוח לפי פרופיל אתר כדי לצמצם את החיפוש, ואז השוו ליומני היישום מאותה תקופה. תעדו את הבקשה הלוגית, את ה-requestId שלה, את מזהה המשימה שהוחזר ואת הסטטוס הסופי.
- 2.
חיפוש משימות מרובות עבור בקשה אחת
כמה מזהי משימות שונים עבור פתרון מתוכנן אחד יכולים להסביר חיובים נוספים אם המשימות מגיעות למצב מוכן. יש להבחין בין פתרונות חלופיים שנוצרו במכוון לבין ניסיונות חוזרים שבוצעו משום שתגובה אבדה.
- 3.
שחזור בקשות יצירה שחרגו מזמן ההמתנה
חריגה מזמן ההמתנה לחיבור אינה מוכיחה שיצירת המשימה נכשלה. אם מזהה המשימה בידיכם, אחזרו את המשימה הזו. אחרת, שלחו שוב את אותה בקשת משימה עם ה-requestId המקורי שלה כדי לשחזר את המשימה הקיימת במקום ליצור משימה לוגית חדשה.
- 4.
הקצאת requestId לפני הניסיון הראשון
השתמשו ב-requestId אחד לכל פתרון מתוכנן ושמרו עליו בניסיונות חוזרים. הוא מקבל 1–64 אותיות ASCII, ספרות, קווים תחתונים או מקפים. אותו מזהה עם אותה בקשת משימה מחזיר את המשימה הקיימת; שימוש בו עם קלט שונה יוצר התנגשות.
בבדיקת יצירה כפולה, ספרו משימות נפרדות ולא רק ניסיונות HTTP. ניסיונות חוזרים מרובים שמחזירים את אותו מזהה משימה לא יצרו משימות מרובות.
מקורות ותיעוד API
הפעלת המשימה הראשונה שלך.
התחילו עם $5 בקרדיט לסביבת העבודה.