מדוע Magento 2 API מאט ומחזיר שגיאות תחת עומס
Magento 2 API הוא, בעצם, חזית מעל הקטלוג, המחירים, המלאי וההזמנות: REST לפעולות סינכרוניות, GraphQL לוויטרינה, ונקודות קצה מותאמות אישית למשימות שאינן קיימות בליבה. כל עוד התעבורה קטנה, הכול נראה תקין.
תחת עומס מתחילים להתגלות צווארי הבקבוק של האינטגרציה, שאינם נראים במצב רגוע: שגיאות API נופלות בכמויות, התגובות מתארכות, וחלק מהבקשות פשוט נופלות בגלל timeout.
הדבר הראשון שכדאי לבדוק הוא כיצד בנויות השאילתות. אוסף עם קשרים טעונים עבור כל מוצר הופך בקשה אחת למאות פניות למסד הנתונים, וזה המקום הראשון שבו העומס על ה-API עובר לצמיחה לא לינארית.
השני הוא המטמון: אם תגובות הקטלוג אינן נשמרות במטמון ברמת שכבת ה-API, כל קריאה מחשבת מחדש את אותו הדבר, למרות שהנתונים לא השתנו. השלישי הוא נעילות מסד הנתונים: כתיבות מקבילות של מלאי והזמנות מתחילות להמתין זו לזו, ובמקום שגיאה הלקוח מקבל בקשה תקועה.
קטגוריה נפרדת היא המגבלות בצד האינטגרציות. מערכת חיצונית עשויה לקצץ את תדירות הפניות, ואז האשם לכאורה הוא Magento 2 API, למרות שהבעיה היא באופן שבו בנויה התור וניסיונות חוזרים.
אנו מפרקים את ארבעת השכבות האלה לפי הסדר — שאילתות, מטמון, נעילות, מגבלות — ומראים כיצד כל אחת נסגרת ברמת התצורה והקוד, ולא באמצעות "הגדלת השרת".
מה נותן שכבת API בנויה היטב לעסק ולאינטגרציות
מהירות תגובה תחת עומס
קטלוג עם עשרות אלפי פריטים וסל קניות בשיא המבצע — אלו אלפי בקשות מקבילות בשנייה.
שכבת API בנויה היטב אחראית לתגובה בשברירי שנייה במקום שבו אינטגרציה "גולמית" מתחילה להיתקל במגבלות ולהחזיר timeout-ים: שליפות כבדות עוברות ל-cache, בקשות חוזרות לא מחושבות מחדש, והתשובות מוחזרות בצורה קומפקטית.
הוויטרינה, האפליקציה לנייד וערוצי השותפים מקבלים נתונים בו-זמנית, ללא תורים וללא מהירות "צפה".
יציבות החלפת נתונים עם מערכות חיצוניות
אינטגרציות נשברות לא מעומס, אלא מתשובות בלתי צפויות: המחסן החזיר רשימה חלקית, שירות התשלומים שלח שגיאה, שירות המשלוחים שינה פורמט. אנחנו מטמיעים ניסיונות חוזרים עם השהיה גדלה, בידוד של ערוץ תקול ויומן החלפת נתונים שמראה היכן בדיוק אבדו הנתונים.
שירות אחד שקרס מפסיק לגרור אחריו את האחרים — הזמנות, מלאי וסטטוסים מגיעים ליעדם, ופערים נבדקים לפי הלוג, ולא בחיפוש עיוור.
פחות פעולות ידניות
כל החלפת נתונים שנעשתה קודם ביד — ייצוא מחירונים, התאמת מלאי, העברת הזמנות למערכת החשבונאית — עוברת למצב אוטומטי לפי לוח זמנים או אירוע. העובד מפסיק להיות "גשר" בין המערכות: הנתונים מסתנכרנים בעצמם, והאדם מתערב רק במקרים שנויים במחלוקת. זה מפחית את שיעור שגיאות ההקלדה ומפנה זמן לצוות למשימות שבאמת דורשות החלטה.
מוכנות לערוצים חדשים
כאשר שכבת ה-API מתועדת ויציבה, חיבור ערוץ חדש — מרקטפלייס, ויטרינת שותפים, לקוח נייד — מפסיק להיות פרויקט נפרד. הצרכן החדש מקבל את אותן נקודות גישה מוכחות עם כללים ומגבלות ברורים, ולא אוסף נתונים "איך שיצא". בדיוק משום כך ההשקעה ב-API מחזירה את עצמה לא בגרסה הראשונה, אלא בכל חיבור נוסף.
REST, GraphQL ונקודות קצה מותאמות אישית: השוואת גישות
בחירת פרוטוקול התקשורת אינה החלטה של טעם אישי, אלא תוצאה של מי ובאיזו תדירות ניגש לנתונים. חלון הראווה, אפליקציית המובייל ומערכת האינטגרציה הפנימית מציבים דרישות שונות לאותו קטלוג: אחד זקוק לאובייקט מלא עם עשרה ישויות מקוננות, אחר — לשלושה שדות עבור כרטיס ברשימה. לכן ב-Magento 2 API אנו כמעט תמיד משלבים מצבים, ולא בוחרים אחד "נכון".
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| REST | תקשורת עם מערכות חשבונאות, ייצוא ל-ERP, פעולות כתיבה: הזמנות, מלאי, מחירים | תגובות עודפות: מושך את האובייקט כולו, גם כשצריך שני שדות. מספר הבקשות גדל בעת הרכבת עמודים מורכבים |
| GraphQL | חלון ראווה ולקוחות מובייל: שליפה בדיוק של השדות שנדרשים למסך | קריאה בלבד. שאילתות מורכבות ללא הגבלת עומק מכבידות על מסד הנתונים, נדרשים מגבלות ומטמון |
| נקודות קצה מותאמות אישית | לוגיקה לא סטנדרטית: חישוב משלוח, מחירים אישיים, אגרגטים משירותים חיצוניים | דורשות תחזוקה בעת עדכוני הפלטפורמה וכיסוי בדיקות משלהן |
מדוע REST נשאר לפעולות כתיבה
REST צפוי היכן שטרנזקציוניות חשובה: יצירת הזמנה, ניכוי מלאי, סנכרון סטטוסים. כל קריאה היא פעולה אטומית עם קוד תגובה ברור, קל לחזור עליה ולרשום אותה בלוג. המגבלה — עודפות: כדי להרכיב כרטיס מוצר, הלקוח מבצע מספר פניות, וברשת איטית זה מורגש.
היכן GraphQL מנצח
GraphQL מחזיר ללקוח בדיוק את מערך השדות המבוקש — שאילתה אחת במקום שלוש-ארבע, ונפח התגובה יורד פי כמה. זה מורגש במובייל: עמוד הקטלוג נטען מהר יותר, כי אינו גורר תיאורים וגלריות שאינם מוצגים על המסך. המחיר — קריאה בלבד והצורך להגביל את עומק השאילתות, אחרת לקוח אחד לא זהיר מעמיס על מסד הנתונים.
מתי נקודת קצה מותאמת אישית מוצדקת
נקודת קצה מותאמת אישית נדרשת כאשר המצבים הסטנדרטיים אינם מבטאים את הלוגיקה העסקית: המחיר תלוי בפלח הלקוח, המשלוח מחושב לפי שירות חיצוני, נדרש אגרגט ממספר מקורות. נקודת קצה כזו מספקת חוזה נקי, אך הופכת לחלק מבסיס הקוד — יש לבדוק אותה ולאמת אותה בכל עדכון של הפלטפורמה.
בפועל אנו מקבעים את סכמת התקשורת לפני תחילת העבודה: אילו לקוחות, אילו פעולות, איזה נפח צפוי. זה מסיר מחצית מבעיות האינטגרציה כבר בשלב התכנון.
כיצד אנו מגדירים Magento 2 API: שלבי העבודה
את העבודה מתחילים בספירת מלאי: אוספים את כל הנקודות שבהן מערכות חיצוניות פונות לחנות — אפליקציית מובייל, ERP, מחסן, מרקטפלייסים, CRM. עבור כל אחת מהן מתעדים מה בדיוק היא מבקשת ובאיזו תדירות, כדי להבין את פרופיל העומס האמיתי ולא להסתמך על הנחות.
- ביקורת API. מנתחים את בקשות ה-REST וה-GraphQL הקיימות, מחפשים צווארי בקבוק: בקשות ללא מטמון, שליפות "הכול בבת אחת", כפילויות של קריאות, היעדר הגבלת קצב. התוצר — מפת אינטגרציות עם סימון מה נעשה בו שימוש חוזר, מה נכתב מחדש ומה מוצא משימוש.
- תכנון נקודות קצה. קובעים היכן יספיק REST סטנדרטי, היכן GraphQL ייתן שליפה בבקשה אחת במקום שלוש, והיכן נדרשת נקודת קצה מותאמת אישית ללוגיקה של שותף מסוים. מתעדים חוזים: אילו שדות, אילו קודי תגובה, כיצד מחזירים שגיאות.
- הגדרה ומימוש. מגדירים הרשאות גישה לפי תפקידים, הגבלת קצב בקשות, מטמון לשליפות כבדות. נקודות קצה מותאמות אישית מוציאים למודול נפרד, כדי שעדכון הליבה לא ידרוס אותן.
- בדיקת אינטגרציות. מריצים תרחישים בסביבת בדיקה: תגובות תקינות, כשלים של מערכות חיצוניות, בקשות חוזרות, עומסי שיא. בנפרד בודקים שבמקרה של אי-זמינות של השותף החנות ממשיכה לקבל הזמנות.
- תיעוד API. מתארים כל נקודת קצה: ייעוד, פרמטרים, דוגמאות לבקשה ולתגובה, קודי שגיאה. את התיעוד מנהלים לצד הקוד, כדי שלא יתרחק מהמציאות לאחר עריכות.
- מסירה וניטור. מראים לצוות הלקוח כיצד לקרוא לוגים של אינטגרציות והיכן לראות מדדי כשלים. מסכמים על סף שמעבר לו אנו חוזרים להמשך פיתוח.
סדר עבודה כזה נותן תוצאה צפויה: האינטגרציות מפסיקות ליפול בשקט, וכל מערכת חדשה מתחברת לפי חוזה שכבר תואר, בלי לבנות מחדש את הלוגיקה מאפס.
מדיניות גישה, תפקידים ומגבלות ב-API
הפרדת הרשאות ב-Magento 2 API מבוססת על אינטגרציות: כל אחת מקבלת זוג מפתחות משלה וקבוצת הרשאות מעץ המשאבים. טוקן הגישה חי לזמן מוגבל, מתחדש בבקשה נפרדת, והשיוך לאינטגרציה מאפשר שלילת גישה ממוקדת — בלי להנפיק מחדש מפתחות לשאר הצרכנים.
כך אותו API משרת גם את האפליקציה לנייד, גם את מערכת המחסן וגם את פורטל השותפים, בלי לערבב את ההרשאות שלהם.
תפקידים אנו מתארים דרך משאבי ACL, ולא דרך "מנהל/לא מנהל". אינטגרציה למטמון החזית מקבלת רק קריאה של הקטלוג, אינטגרציה ל-ERP — כתיבת הזמנות ומלאים, ולאנליטיקה מגיעה שליפה בלי הרשאה לשנות נתונים. עקרון ההרשאה המינימלית כאן אינו פורמליות: אם מפתח ידלוף, הנזק מוגבל למשאב אחד ולא לכל מסד הנתונים.
מגבלות בקשות אנו מציבים בשלוש רמות: בפרימטר — לפי IP ומפתח, ברמת האפליקציה — לפי אינטגרציה, וברמת השליפות הכבדות — בנפרד. זה מגן מפני מיצוי מאגר החיבורים למסד הנתונים, כשסקריפט רשלני אחד מפיל את החזית. תעבורת שיא ממבצעים אנו מחלישים בתור ולא בסירוב לשירות.
עבור GraphQL אנו מגבילים בנפרד את העומק ואת המורכבות של הבקשות — אחרת בקשה מקוננת אחת בעשרה רבדים שולפת את הקטלוג כולו. אנו מתעדים כל קריאה עם מזהה האינטגרציה, כדי שתקלה תנותח לפי עובדות ולא לפי השערות.
אנו עובדים עם Magento בענף העדכני — מנגנוני ACL, טוקנים ותrottling כבר קיימים שם, יש להגדיר אותם נכון ולא להמציא מעליהם.
לסיכום: גישות מונפקות לפי משימה, מפתחות נשללים בלי השבתה, ומגבלות לא מאפשרות לצרכן אחד להפיל את השירות עבור האחרים.
מה הלקוח מקבל לאחר הגדרת API
לאחר הגדרת API הלקוח מקבל לא "נקודת קצה עובדת", אלא ערכה שלפיה ניתן לפתח ולתחזק את האינטגרציה ללא המפתח. להלן מה בדיוק נכלל במסירה.
- תיעוד API — תיאור כל המתודות עם דוגמאות לשאילתות ולתשובות, קודי שגיאה ומגבלות. מפתח מצד הלקוח או קבלן חדש מתחבר דרכו, בלי לקרוא את קוד המקור.
- תרשימי אינטגרציות — אילו מערכות מחליפות נתונים, באיזה כיוון, באיזו תדירות ומה קורה כאשר אחד הצדדים אינו זמין. התרשים עונה על השאלה "למה ההזמנה נשלחה ל-ERP פעמיים", בלי להרים לוגים ידנית.
- תצורות סביבות — ערכות פרמטרים נפרדות לסביבת בדיקות ולסביבת עבודה, מפתחות גישה, הרשאות תפקידי API. שאילתות בדיקה אינן נשלחות למערכות הייצור, והמפתחות אינם מונחים בקוד.
- נהלי תמיכה — מה מנוטר, אילו שגיאות נחשבות קריטיות, למי וכיצד מועבר אות ההתראה, מי מגיב ובאילו זמנים. התורן רואה את הבעיה לפני שהלקוח מבחין בה.
- הוראות לצוות — כיצד להוסיף מתודה חדשה, לשנות את מבנה התשובה, לבצע rollback לשינוי כושל. פעולות שגרתיות מבוצעות שלב אחר שלב, בלי לפנות אלינו.
- מערך בדיקות אוטומטיות — בדיקות של תרחישי החלפה מרכזיים, המופעלות לפני כל שחרור. שינוי בקטלוג או בביצוע הזמנה אינו שובר את האינטגרציה באופן סמוי.
- יומן שינויים — מה ומתי השתנה בחוזה ה-API, אילו גרסאות עדיין נתמכות, כיצד לעבור לגרסה חדשה. עדכונים בצד הלקוח אינם הופכים להפתעה למערכות משיקות.
בנפרד אנו מגדירים את הגבולות: אילו נקודות קצה ציבוריות, אילו סגורות באימות, היכן קיימות מגבלות על קצב השאילתות. זה מסיר את רוב השאלות "למה סירבו לנו לגישה" עוד לפני הפנייה הראשונה.
תארו את המשימה — נחזור עם הערכה ותוכנית: אילו ארטיפקטים נדרשים בדיוק לקונטור שלכם ובאיזה היקף.
במה שונה REST מ-GraphQL ב-Magento 2 API?
REST ב-Magento 2 הוא מודל מבוסס משאבים: כל סוג ישות (מוצר, קטגוריה, הזמנה, לקוח) נגיש בכתובת משלו, והשליפה נשלטת על ידי פרמטרים של הבקשה.
התשובה מגיעה בשלמותה בצורה שבה שכבת השירות מחזירה אותה, ולכן הלקוח אינו יכול לבקש "רק שם, מחיר ומלאי" — הוא מקבל את האובייקט כולו ומשליך את המיותר בצד שלו.
עבור פעולות בודדות ואינטגרציות "כתיבה/קריאה" זה צפוי ונוח: מטמון ברמת HTTP, קודי תגובה ברורים, דיבוג פשוט דרך לקוח HTTP רגיל.
GraphQL ב-Magento 2 פותר משימה אחרת — הוא בנוי סביב הצרכים של הוויטרינה. הלקוח מתאר בבקשה בדיוק את השדות שהוא צריך, ומקבל תשובה אחת במקום שרשרת פניות למספר נקודות קצה. זה קריטי לוויטרינות ב-React, Vue ואפליקציות מובייל, שבהן חשובים הזמן עד הרינדור הראשון ונפח התעבורה.
הצד השני של המטבע — מגבלות נוקשות: GraphQL בליבה מכוון לקריאה, חלק מהפעולות הניהוליות והכתיבה דרכו אינן זמינות, ובקשות מורכבות דורשות בקרת עומק ועלות, אחרת בקשה רשלנית אחת מכבידה על מסד הנתונים בסריקה כבדה.
בחירת הגישה אינה "מה מודרני יותר", אלא "איזה פרופיל עומס". REST מנצח במקומות שבהם נדרשות פעולות המוניות, אינטגרציות עם מערכות חשבונאות, החלפה עם שירותים חיצוניים וניהול: הוא נותן גישה מלאה לשכבת השירות ומתרחב בצורה צפויה לפי מספר הוורקרים.
GraphQL מנצח בוויטרינה: פחות סבבי רשת, פחות עומס על הערוצים, שליפה גמישה עבור מסך מסוים. בפועל החזק ביותר הוא שילוב היברידי — GraphQL לוויטרינה וללקוחות מובייל, REST לאינטגרציות ותרחישי שירות, עם שכבת לוגיקה עסקית משותפת מתחת לשניהם.
בנפרד כדאי להתייחס לנקודות קצה מותאמות אישית. כאשר המסלולים הסטנדרטיים אינם מספיקים — למשל, נדרשת אגרגציה של נתונים ממספר מקורות או פעולה עסקית ייחודית — אנו מוסיפים מסלול משלנו למודול ומוציאים את הלוגיקה לשכבת השירות, ולא לקונטרולר.
נקודת קצה כזו עושה שימוש חוזר במאגרים קיימים ואינה משכפלת כללים, ולכן אינה סוטה משאר המערכת בעת שינויים. ההחלטה אם להרחיב REST, להוסיף סכימה ל-GraphQL או ליצור מסלול נפרד מתקבלת לפי המשימה, ולא לפי הרגל — מכך תלויים גם מהירות הוויטרינה וגם עלות התחזוקה.
מקרה בוחן: האצת חילופי נתונים עם מערכות חיצוניות
מה היה לפני
אצל הלקוח — חנות אינטרנטית על Magento 2 עם חילופי נתונים בין המחסן, מערכת הנה"ח והחזית. הקטלוג והמלאי סונכרנו באמצעות משימת אצווה לילית: הייצוא נמשך מספר שעות, ובין ההרצות הנתונים בחזית היו שונים מהמלאי בפועל. הקונה ביצע הזמנה על מוצר שכבר אינו קיים, המנהלים הסירו פריטים ידנית, וחלק מההזמנות בוטלו בדיעבד.
גרועה יותר הייתה הבעיה השנייה — סוג השגיאות. נקודת הקצה הסטנדרטית של REST החזירה את כל אובייקט המוצר בשלמותו, כולל עשרות מאפיינים וקשרים שאינם בשימוש.
בייצוא המוני הדבר יצר עומס על בסיס הנתונים, פסקי זמן וכשלים "מרחפים": חלק מהבקשות נפלו בגלל חריגת זמן, והחילוף הושלם באופן חלקי. לאתר אילו פריטים בדיוק לא הגיעו היה כמעט בלתי אפשרי — היומן תיעד רק את עצם הכשל.
מה שינו
העברנו את החילוף מאצווה לאירועים וכתבנו מחדש את נקודות הגישה לנתונים. במקום בקשת REST כבדה אחת על כל הקטלוג, ביצענו שליפה דרך GraphQL: הלקוח מבקש בדיוק את השדות הדרושים למחסן ולמערכת הנה"ח — מלאי, מחירים, מזהים.
נפח הנתונים המועברים בפעולה אחת הצטמצם פי כמה, וזמן התגובה לבקשה טיפוסית ירד מכמה שניות לשברירי שנייה.
לתרחישים לא סטנדרטיים — קליטת משלוחים והתאמת מנות — הוספנו נקודות קצה מותאמות אישית עם ולידציה משלהן לנתוני הקלט. כל בקשה כעת או עוברת במלואה, או נדחית עם שגיאה מובנת, ללא שינויים שיושמו חלקית. הדבר הסיר את עצם סוג החילופים ה"חצויים": פערים שקודם צפו לאחר יממה אינם נוצרים עוד.
מה נהיה
החילוף בין המערכות מתבצע בזמן אמת, ולא פעם ביממה: המלאי בחזית תואם את המלאי בפועל ברגע ביצוע ההזמנה. ביטולים בגלל מוצר חסר כמעט נעלמו, ותיקון פריטים ידני על ידי המנהלים אינו נדרש עוד.
העומס על בסיס הנתונים בשעות השיא ירד, משום שנעלמו הייצואים הכבדים בלילה והשליפות המיותרות של שדות שאינם בשימוש.
תוצאה נפרדת — צפיות מראש של כשלים. שגיאות אינטגרציה מגיעות כעת עם ציון הישות הספציפית והסיבה, ולא כ"החילוף לא עבר". המהנדס התורן רואה את הבעיה לפני שהקונה מבחין בה, ומטפל בה באופן ממוקד.
ספקות טכניים נפוצים בנוגע ל-API
REST ו-GraphQL ב-Magento 2 מתקיימים זה לצד זה ולא מחליפים זה את זה: REST נשאר לפעולות ניהוליות, לאינטגרציות עם מערכות חשבונאות ולקריאות חוזרות (webhooks), בעוד GraphQL מיועד לחלון הראווה, שבו חשוב לקבל בבקשה אחת מוצר, מחירים, מלאי ותוכן ללא סדרה של קריאות עוקבות.
התאימות מובטחת ברמת חוזי השירות (service contracts): כל עוד המודול מצהיר על ממשקים ואינו שובר את החתימות שלהם, שני השכבות פועלות מעל אותה לוגיקה עסקית, והוספת נקודת קצה מותאמת אישית אינה מחייבת כתיבה מחדש של הקיימות.
אנחנו כבר משתמשים ב-REST — האם מעבר ל-GraphQL ישבור את האינטגרציות הקיימות?
לא, השכבות אינן מתנגשות. GraphQL מתחבר כתעבורה נפרדת מעל אותם חוזי שירות, והנתיבים הישנים של REST ממשיכים להגיב. את המיגרציה מבצעים בשלבים: תחילה תרחישי חלון הראווה, לאחר מכן משניים, עם עבודה מקבילה של שתי השכבות ובדיקת התאמה של התגובות לזהות הנתונים.
כיצד לדעת שה-API יעמוד בעומס שיא?
מריצים בדיקות עומס על פרופיל הקרוב לזה הייצורי: שליפות המוניות של הקטלוג, ביצוע הזמנה, סנכרון מלאי. מסתכלים לא על זמן התגובה הממוצע, אלא על ההתנהגות באחוזון ה-95 ובמצבי כשל של שירותים חיצוניים — דווקא שם מתגלים שאילתות לא מותאמות ונעילות. בהתאם לתוצאות מוסיפים מטמון (caching) והגבלת קצב הפניות.
מה לעשות עם אינטגרציות שנכתבו על ידי מפתח שאינו שלנו?
מתחילים במיפוי מלאי: אילו נקודות קצה נקראות, באיזו תדירות, אילו שדות נקראים ונכתבים. לאחר מכן מקבעים את החוזה בבדיקות — כך שינוי בלוגיקה הפנימית אינו שובר אינטגרציה זרה באופן בלתי מורגש. התמיכה מצטמצמת לתקנון: ניהול גרסאות של נתיבים, תיעוד קריאות וסדר ברור של חזרה לאחור בעת תקלה.
כיצד לחזור לאחור משינוי API שלא צלח?
החוזים מנוהלים בגרסאות, והנתיבים הישנים נשמרים לתקופת המעבר, ולכן חזרה לאחור היא החזרת הגרסה הקודמת של המודול ללא שינויים בצד הצרכנים. לפני העלאה מריצים מערך בדיקות תאימות, כדי שהחזרה לאחור תהיה החלטה מושכלת ולא תגובה לאירוע.
נדון במשימה שלך ב-API
כדי שההערכה תהיה עניינית ולא "פחות או יותר", אנחנו צריכים מינימום של הקשר: אילו מערכות צורכות נתונים, אילו פעולות קריטיות, האם יש מגבלות על עומס ולוחות זמנים. עם זה ננתח את נקודות הקצה, הסכמות והרשאות הגישה הקיימות ונחזור עם תוכנית עבודה שבה כל שלב קשור לתוצאה.
- ניתוח ה-API הנוכחי: אילו בקשות REST ו-GraphQL כבר בשימוש, היכן יש כפילות בקריאות ואילו נקודות קצה מאטות את תגובת התצוגה.
- סכמת אינטגרציות: מפת הצרכנים — אפליקציית מובייל, ERP, מחסן, מרקטפלייסים — ואילו נתונים כל אחד מהם מושך ובאיזו תדירות.
- הערכת היקף: רשימת נקודות קצה לשיפור או ליצירה, סדרי עדיפויות לפי ההשפעה על תהליכים עסקיים.
- תוכנית עבודה לפי שלבים: תכנון חוזים, מימוש, בדיקות, בדיקת עומס, העלאה לפרודקשן.
- מדיניות גישה ואבטחה: טוקנים, תפקידים, מגבלות לפי מתודות ומגבלות בקשות.
- סכמת rollback: כיצד להחזיר גרסה קודמת של החוזה ללא השבתה עבור הצרכנים.
- הרכב התיעוד: תיאור נקודות קצה, דוגמאות לבקשות ולתגובות, תקנון שינויים.
תאר את המשימה — אילו מערכות צריך לחבר ומה מפריע כרגע — ונחזור עם הערכת API ותוכנית עבודה. לאחר מכן נתאם את השלבים ונתחיל.
