Brilliancy of quality
ארכיטקטורה

JSON API ליישומים ניידים וחיצוניים

Sapphire I.C.D.S.

אינטגרציה אינה אמורה להיות תלויה בסימון של דף אינטרנט

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

Sapphire I.C.D.S. מספקת לשם כך HTTPS JSON API נפרד. הוא מקבל בקשות מובנות, מחזיר תשובות למכונה, אינו מציג דפי משתמש ואינו דורש מן הלקוח להכיר את מסד השרת. ה-Roadmap הציבורי מציין אותו כבסיס שפורסם ללקוחות טבעיים ולאינטגרציות עסקיות.

JSON הוא פורמט ההחלפה, לא כל הארכיטקטורה

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

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

השרת בודק סשן וזהות

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

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

מודולים מפרסמים רק פעולות מפורשות

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

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

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

תרחישים עסקיים מתאימים

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

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

JSON API אינו MCP חיצוני

JSON API מיועד ליישומים ניידים וארגוניים בעלי תהליך מתוכנן מראש. MCP חיצוני מיועד ללקוחות AI שמגלים כלים. אין להחליף בין ההרשאות ומדיניות הפרסום שלהם.

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

מה היישום הלקוח צריך לטפל בו

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

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

דרך היישום

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

העסק יכול לפתח יישומים משלו בלי לשכפל לוגיקת שרת. המנהל הטכני מקבל גבול אינטגרציה מנוהל עם אימות משותף ופקודות מודולריות. JSON API מרחיב את Sapphire I.C.D.S. מעבר לממשק האינטרנט ושומר נתונים, הרשאות וכללי תהליך בסביבת השרת המוסמכת.