WEBA

API: מה זה?

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

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

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

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

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

כלים שהמונח חי בהם