את היסודות של REST ופיתוח RESTful API

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

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

REST עבור מפתחי אינטרנט

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

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

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

בשילוב כל זה, ממשקי API של RESTful הם ממשקי API שעוקבים אחר הארכיטקטורה של REST.

מה בדיוק היא האדריכלות REST?

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

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

אין כל הנחיות ספציפיות במיוחד כמו המפרט W3C HTML5 אשר עלול להוביל לבלבול, וכן miasma של אי ודאות סביב REST המינוח.

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

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

כפי שניסח זאת וינאי סהני, “ממשק API הוא ממשק משתמש של מפתח.” הכל צריך להיות קל לשימוש, ולספק חוויית משתמש נהדרת. RESTful APIs שואפים לעשות בדיוק את זה.

Key Takeaways עבור RESTful APIs

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

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

באופן כללי יש ארבע פקודות היה גישה לממשקי API של RESTfulYou

1. לקבל לאחזור אובייקט
2. הודעה ליצירת אובייקט חדש
3. PUT לשינוי או להחלפה של אובייקט
4. DELETE להסרת עצם

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

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

עם זאת לא רבים APIs RESTful אפילו ללכת רחוק. שקול Pokéapi שהוא מסד נתונים חינם פוקימון API. זה פתוח לציבור עם הגבלת שיעור הגון (הגבלת משתמשים למספר מסוים של בקשות ה- API על פני תקופה של זמן), אבל רק מאפשר לקבל שיטה לגישה למשאבים. ניתן לכנות זאת במפורש א ממשק API לצריכה בלבד.

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

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

גישה למשאבי ממשק API

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

כתובות אתר מסוימות יכולות לכלול ספריית קידומת כמו / v2 / עבור גרסה מעודכנת 2 של ממשק API קודם. זה נפוץ עבור מפתחים שאינם רוצים לפחת את ה- API שלהם 1.x, אבל עדיין רוצה להציע את המבנה החדש.

אני באמת נהנה זה לכתוב כיסוי מבני כתובת אתר בסיסיים ודוגמאות משירותים אחרים.

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

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

• Reddit API
• ממשק API של GitHub
• ממשק API של Flickr
• Pinterest API

בניית API משלך

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

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

אבל בואו נסתכל כמה עקרונות בסיסיים של ארכיטקטורת API.

בניית נקודות קצה

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

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

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

 $ / tweet / 15032934882934 $ / tweets / 15032934882934 

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

הגדר סוג החזרה

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

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

אם אתה רק מתחיל, שקול לרמות את הדרכות האלה של dev:

• REST אתר הדרכה API
• כתיבת API פשוט REST
• בניית שירות אינטרנט חמוד

משאבים נוספים

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

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

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

ספרים

• REST ממשק API עיצוב
• ממשק אינטרנט משוכלל
• שירותי אינטרנט
• Unisturbed REST: מדריך לעיצוב API מושלם

מאמרים

• מדריך למתחילים ל- HTTP ו- REST
• יצירת ממשק API RESTful
• RESTful משאבים למתן שמות מדריך
• יצירת ממשק API של REST באמצעות ערכת ה- MEAN