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

אבל איך יישומים מתקשרים זה עם זה? ובכן, הם עושים זאת דרך APIs – ממשקי תכנות יישומים. במאמר זה, תלמדו מה זה APIs. נתמקד במיוחד ב- Web APIs ובעיצובם ופיתוחם.

מה זה Web API?

Web APIs הם סוג של API המיועדים לשימוש באינטרנט. במילים אחרות, יישומי תוכנה, מערכות ושירותים מבוססי אינטרנט משתמשים ב- Web APIs כדי להחליף מידע באינטרנט. הם שולחים בקשות ומקבלים תגובות, בדרך כלל בפורמטים כמו JSON או XML.

Web APIs ממלאים תפקיד קרדינלי בפיתוח תוכנה מודרני מהסיבות הבאות:

  1. אינטראופראביליות: APIs הם ניטרליים מבחינה טכנולוגית, כלומר הם מאפשרים למערכות תוכנה שונות לתקשר זו עם זו ללא קשר לערימת הטכנולוגיה. זה מאפשר למפתחים לשלב יישומים שונים בצורה חלקה.

  2. סקלאביליות: Web APIs תומכים בפיתוח מודולרי, המאפשר לבנות, לנפות ולסקייל רכיבים שונים של יישום באופן עצמאי. זה משפר מאוד את הסקלאביליות של המערכת.

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

גישות לפיתוח ממשקי API של רשת

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

  • REST – העברת מצב מייצגת (REST) משתמשת בפרוטוקול HTTP כדי לבצע פעולות. הם פועלים בצורה חסרת מצב, כלומר כל בקשה חייבת לכלול את כל המידע הנדרש כדי שהמקבל יוכל לעבד ולענות.

  • SOAP – פרוטוקול גישה לאובייקטים פשוט (SOAP) משתמש ב-XML כדי להחליף מידע בצורה מובנית.

  • GraphQL – משמש לשאילתות ול-manipulציה של APIs.

  • gRPC – מסגרת קריאות פרוצדורה מרחוק שמשתמשת ב-HTTP/2 להעברת מידע.

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

הבנת הדרישות והמטרות

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

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

הגדרת המשאבים והנקודות סיום

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

שיטות עבודה מומלצות מציעות להשתמש בשמות עצם עבור משאבים בנקודות הסיום במקום פעלים שעשויים להצביע על פעולה על המשאב.

שקול את הדוגמה הבאה: https://api.example.com/products

נקודת הקצה הזו עוקבת אחרי השיטה הטובה ביותר של שימוש בשמות עצם עבור המשאב (במקרה הזה, products). שים לב כיצד השתמשתי בצורת הרבים – מוצרים? מומלץ גם להשתמש ברבים אם אתה עובד עם אוסף של אובייקטים.

עם זאת, נקודת הקצה הבאה https://api.example.com/add-product אינה מומלצת כי היא משתמשת בפועל ומנסה לתאר פעולה על המשאב. גישה זו יכולה להפוך למורכבת עבור פעולות יותר מסובכות.

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

למשל: https://api.example.com/categories/{categoryId}/products/{productId}.
כאן, אנו מגדירים נקודת קצה ששומרת על היררכיה ברורה בין משאבי category ו-product.

שימוש בשיטות HTTP ובקודי סטטוס

ב-REST APIs, HTTP משמש לתקשורת בין הלקוח לשרת. ל-HTTP יש שיטות סטנדרטיות שנעשה בהן שימוש בעיקר לביצוע פעולות על משאבים. להלן רשימה של שיטות אלו יחד עם מטרותיהן:

  • GET – קבל את פרטי המשאב. פרטים אלו מוחזרים על ידי השרת בגוף הודעת התגובה.

  • POST – צור משאב חדש. פרטי המשאב שצריך ליצור נשלחים בגוף הודעת הבקשה.

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

  • DELETE – הסר משאב.

  • PATCH – עדכן חלקית משאב. השינויים שצריך לבצע על המשאב נשלחים בגוף הודעת הבקשה.

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

קודי מצב משקפים את התוצאה הסופית של בקשה. להלן כמה מקודי המצב הנפוצים של HTTP שניתן להשתמש בהם:

  • 200 OK

  • 201 נוצר

  • 204 אין תוכן

  • 400 בקשה רעה

  • 401 לא מורשה

  • 403 נאלץ לאסור

  • 404 לא נמצא

  • 500 שגיאה בשרת פנימי

  • 503 שירות אינטרנט לא זמין

  • 504 מגבלת זמן עברת משדר

השתמש בקוד ״HTTP status code״ המתאים למידה המדוייקת של הבקשה שהסוף השירות שלך מעבד. ניתן גם ליישם קוד ״HTTP status code״ מותאם להתנהגויות מיוחדות של היישומך.

אסטרטגיות לגידול

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

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

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

אפילו הגירסה של ה API יכולה להיות בדרכים שונות. הנה כמה שיטות:

  • גירסת כתובת: הכנס את מספר הגירסה בתוך הנתיב הכתובת. לדוגמה, https://api.example.com/v1/products.

  • פרמטר שאלה גירסתי: ספציפי את מספר הגירסה בתוך משתנה שאלה בכתובת. לדוגמה, https://api.example.com/products?version=1.

  • התחברות ראשית גירסתי: הכנס את מספר הגירסה בראשי הגיבורים של הבקשה. לדוגמה, בעזרת ראש הגיבורים מותאם מוצרך כמו X-API-Version: 1.

  • משא ומתן על תוכן: ציין את הגרסה בכותרת Accept של הבקשה, בדרך כלל באמצעות סוגי מדיה. לדוגמה, Accept: application/vnd.example.v1+json.

  • גרסת משובצת: שלב את מספר הגרסה בתוך סוג המדיה של התגובה. לדוגמה, application/vnd.example.product-v1+json.

שיקולי אבטחה

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

  1. יש ליישם HTTPS כדי להצפין את המידע המועבר בין הלקוח לשרת.

  2. יש ליישם אימות והרשאה כדי להבטיח שרק משתמשים עם ההרשאות הנכונות יכולים לבצע פעולות על המשאבים. שיטות נפוצות כוללות אימות בסיסי, אימות Bearer או Token, JWT, ו-OAuth 2.0. בנוסף, יש ליישם בקרת גישה מבוססת תפקידים כדי לנהל גישה למשאבים.

  3. יישם אימות קלט וחיטוי כדי למנוע התקפות פגיעות כמו הזרקת SQL ו-Cross-Site Scripting (XSS).

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

תיעוד

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

התיעוד חייב להיות מקיף, קל להבנה ולעמוד בסטנדרטים המקובלים. כלול דוגמאות של גוף הבקשה והתשובה, קודי סטטוס HTTP בשימוש, ועוד. תוכל לעקוב אחרי המפרט Open API לתיאור ה-APIs ה-RESTful שלך.

אסטרטגיות מיון, סינון ודיפרנציאציה

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

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

ניטור שימוש, רישומים ובריאות

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

הסיכון

APIs, בסוף היום בעיקר אפילו אפילו Web APIs, הם חיוניים ליישומים המתקשרים מעל האינטרנט.

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

אם מעניין אתה במאמר הזה, אפשר להסתכל על מאמרי