מה זה REST API? הסבר פשוט + משרות פתוחות בישראל

REST הוא סגנון לבניית ממשק מעל HTTP, שבו כל דבר במערכת מיוצג כמשאב בעל כתובת, ופועלים עליו בעזרת שיטות HTTP סטנדרטיות. זהו הסגנון הנפוץ ביותר לממשקי ווב. בלוח HiTakeJob פתוחות כרגע 26 משרות שמזכירות REST API, 52 שמזכירות Node.js ו-365 שמזכירות Python.

העיקרון המרכזי: משאבים, לא פעולות

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

שיטה	מה היא עושה	חוזרת על עצמה בבטחה?
GET	קריאה בלבד	כן
POST	יצירת משאב חדש	לא - קריאה כפולה יוצרת שניים
PUT	החלפה מלאה של משאב	כן
PATCH	עדכון חלקי	תלוי במימוש
DELETE	מחיקה	כן

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

מה ההבדל בין PUT ל-PATCH?

PUT מחליף את המשאב כולו במה שנשלח - שדה שלא נשלח נמחק או מאופס. PATCH מעדכן רק את מה שנשלח. הבלבול ביניהם מייצר באג נפוץ: לקוח ששולח PUT עם שני שדות בלבד ומופתע לגלות ששאר השדות התרוקנו.

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

איך בונים נתיבים נכון

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

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

איך מטפלים בשינויים בלי לשבור לקוחות

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

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

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

מה בדרך כלל חסר במימוש

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

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

REST מול GraphQL מול gRPC

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

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

מה זה אומר שממשק הוא חסר מצב

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

מה שואלים על זה בראיון

זהו אחד הנושאים הוודאיים בראיון Backend בישראל. השאלות שחוזרות:

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

הכנה רחבה יותר נמצאת בשאלות ראיון Backend, ואפשר לראות משרות במשרות REST API.

שאלות נפוצות

REST זה פרוטוקול?

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

איזה קוד סטטוס מחזירים ביצירה מוצלחת?

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

מה עושים כשצריך פעולה שאינה CRUD?

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

איך מאבטחים REST API?

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

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

26 משרות פעילות מזכירות REST API במפורש, אבל המספר מטעה כלפי מטה: כמעט כל משרת Backend כוללת עבודה מול ממשקים כאלה גם בלי שהמונח מופיע במודעה. 52 משרות מזכירות Node.js ו-365 מזכירות Python.

איך מטפלים בפעולה שלוקחת זמן רב?

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

מה זה HATEOAS וצריך להכיר?

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