קצת אחרי בועת הדוט קום, החלה מלחמת אופל בין SOAP ל- REST, שמטרתן הייתה לקבוע סטנדרט לבנייה ותקשורת בין “Web Services”, כלומר לקבוע איך בונים מערכות המתקשרות ביניהן דרך האינטרנט הגדול. בקרב הזה REST ניצח, לפחות לעת עתה.
את המושג REST, שנקרא Representational State Transfer טבע לראשונה רוי פילדינג, כמה שנים אחרי שמייקרוסופט שיחררה את הפרוטוקול שלה: SOAP. עם השנים REST הפכה לגישה הדומיננטית ביותר לבניית Web Services, בעיקר בגלל ש REST הייתה פשוטה יותר, נוחה, והרבה יותר גמישה וסלחנית. למשל, לפי REST אפשר להעביר מידע בתצורות שונות כמו ג’ייסון, XML וכד’. ב SOAP, אפשר להעביר מידע רק בתצורת XML.
קשה להשוואת בין SOAP ל REST, מכיוון שאי אפשר. REST היא ארכיטקטורה עם סט חוקים שצריך ליישם, ו-SOAP הוא פרוטוקול. אך עדיין סרביסים התפלגו לכאלה שנבנים תוך שימוש ב SOAP כפרוטוקול תקשורת, וכאלה שעומדים בתנאים של REST.
הגישה של REST מכריחה כל מערכת שרוצה להיחשב כ ‘RESTful’ לעמוד בתנאים הבאים:
א) לחלק את המבנה לקליינט ושרת. הקליינט מציג את המידע, והשרת מעבד ושומר את המידע. שניהם צריכים להיות מופרדים ולא קשורים אחד לשני (או לדעת על קיום וזהותם אחד של השני).
ב) Stateless - המערכת לא צריכה לנהל שום סטייט של אף קליינט. זה אומר שהקליינט צריך לספק לשרת מספיק מידע בקריאה בשביל שהשרת יוכל לזהות את הקליינט ולבצע את הפעולות שהקליינט דורש ממנו.
ג) Caching- השרת יכול להחזיר לקליינט בקשה ולהצהיר לקליינט שהוא יכול לשמור את המידע שקיבל, ולהשתמש בו עד לפרק הזמן שהשרת ממליץ. כך הקליינט יכול לחסוך קריאה לשרת כשיש בידו את המידע העדכני. עוד דרך יכולה להיות בעזרת ETAG, כשמסמנים טוקן ייחודי לתשובה, והשרת והקליינט יכולים לוודא ביניהם אם המידע השתנה. אם המידע בשרת לא השתנה, הטוקן ETAG יהיה אותו טוקן מהתשובות הקודמות. אם הטוקן שונה- המידע השתנה ויש לבקש את המידע מחדש (עם טוקן חדש).
ד) האפשרות להרכיב שכבות בין התקשורת- הקליינט ו\או השרת אינם חייבים לתקשר ביניהם ישירות. למשל אפשר להכניס middle man כמו פרוקסי שייתן עוד שכבת אבטחה או לוגיקה ביניהם. כל זה מבלי לשנות משהוא אצל השרת או הקליינט.
ה) ממשק אחיד (Uniform Interface) לתקשורת בין סרביסים ולקליינט-שרת. הבקשה מהקליינט צריכה לציין את צורת המידע שהוא מעוניין להעביר ולקבל, ועליו להעביר מספיק מידע בשביל שהשרת יוכל לעבד את הבקשה ולשנות את המידע בדטאבייס.
לדוגמה, הקליינט רוצה לשלוח מידע בתצורת ג’ייסון, ולשמור את המידע בשרת. היא מזדהה בבקשה, מכניס בהודעה את המידע ומידע נוסף רלוונטי (כמו id כאלה ואחרים), ומשתמש בפרוטוקול מוגדר מראש POST שהשרת יודע שהוא נועד לשמירת מידע.
בנוסף, כדי להקל על הניווט בין המידע שקיים בשרת, כל מידע מקבל ייחוס בדמות של לינק (resource), כך שאפשר לנווט אליו או לשנות את המידע. לדוגמה, אם יש לנו משתמשים והודעות של המשתמשים, אז הלינק המיוחס למשתמש יכול להיות /user ולהודעות /user/id/messages. השאיפה, היא ליצור שפה אחידה שתתרגם צורך מסוים, כלינק.
הפאזל האחרון לממשק האחיד מכיל את המושג HATEOS - Hyper As The Engine Of Application Sate. הכוונה היא שהניווט באתר\סרביס הוא דרך לינקים. השרת מחזיר בתשובתו טקסט (שכיום יהיה בדר"כ אובייקט ג’ייסון) שמכיל בתוכו לינקים, והלינקים הללו הם ההוראות אל הקליינט (או סרביס אחר) לאיך לנווט באתר\סרביס (אנאלוגיה למשתמש שנכנס לעמוד ראשי של אתר כלשהוא, ומשם מתחיל את הניווט שלו לאיך ליצור או לשנות מידע קיים\חדש. השימוש בזה כיום הוא פחות נפוץ, כשרוב הקליינטים כיום מרנדרים לעצמם מראש את הלינקים בתוך הUI, ולא בדיוק מחכים להוראות מהשרת. אם הקליינט צריך לדעת איך לנווט ולגשת אל המידע, הוא פשוט משתמש בדוקומנטציה (כמו swagger).
אם נחבר את כל הממשק, GET /users היא שפה אחידה ל"הבאנה לי את המשתמש". כיום בדר"כ מציינים את תצורת המידע כג’ייסון. בתוך התשובה מהשרת, אנחנו אמורים לקבל גם לינקים המיוחסים למשתמש כמו שמירה (user/) או עריכה (user/1).
נכון ש-REST היא הפופולארית ביותר, אבל אם אפשר לקרוא לכל סרביס שמגדיר את העצמו כ-RESTful, זה מעט שנוי במחלוקת. הרבה מאוד APIs לא באמת יכולים לסמן וי על כל החוקים (למשל, הרבה לא עובדים במדויק לפי HATEOS), אבל עדיין יכולים לתקשר אחד עם השני תחת הסטנדרט של פרוטוקול ה-HTTP. בנוסף, פרוטוקולים חדשים כמו GRPC מתחילים להתעורר ולתפוס תאוצה, כך שאולי נראה גישות חדשות ומודרניות יותר לבנות מערכות שמתקשרות דרך האינטרנט.