**REST** (ראשי תיבות: **Re**presentational **S**tate **T**ransfer) הוא סגנון תוכנה ארכיטקטוני למימוש שירותי רשת (API). הרעיון העיקרי הוא הגדרת משאב מערכת שמצבו עובר שינוי כתוצאה מהאינטראקציה בין מספק השירות והצרכן. המושג הוצג לראשונה על ידי רוי פילדינג בשנת 2000 במסגרת עבודת הדוקטורט שלו. פילדינג הוא אחד המחברים העיקריים של פרוטוקול HTTP, שתחתיו מתבצעים מימושי REST ברוב המקרים.

התפיסה
------

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

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

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

העיקרון המרכזי ב-REST: משאבים
-----------------------------

משאב (Resource) הוא המושג העיקרי ב-REST. לכל משאב יש ייצוג (Representation). הייצוג יכול להיות מספרי או גרפי. היישום מבצע מניפולציות במשאב באמצעות שינויים בייצוג שלו. כך למשל ייצוג של מעגל עשוי להיות ייצוג גרפי של נקודה מרכזית ורדיוס, אבל יכול להיות גם שלושה ערכים מספריים בפורמט של CSV.

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

אילוצים
-------

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

* שרת-לקוח, עובד רק בתפיסת שרת לקוח, כאשר האחד אינו מושפע ממה שמתרחש באחר, למעט המסרים העוברים ביניהם.
* Stateless, ההקשר (context) של הלקוח בפנייה לשרת, אינו נשמר בשרת. מגבלה זו נועדה לשפר את מדרגיות (Scalability) השרת.
* שימוש בזיכרון מטמון, ניתן לשמור תשובות מהשרת בזיכרון המטמון של מחשב הלקוח. המשמעות היא שניתן לעשות שימוש בתוכן התשובה גם בפרקי זמן מאוחרים יותר.
* רב-שכבתיות, הקשר בין הלקוח לשרת לא חייב להיות ישיר. עשוי להיות שרת מתווך. לאפשרות זו משמעות בהקשרים של חלוקת עומסים (Load Balancing) ובהקשר של אבטחת מידע.
* כלל ממשק, ישנם כללים מחייבים לגבי הממשק בין הלקוח לשרת בנושאים כמו: זיהוי המשאב, מניפולציות על משאבים באמצעות היצוג שלהם, מסרים המתארים את עצמם בשלמות (המידע במסר צריך להספיק על מנת לעבד אותו, למשל: איזה Parser יש להפעיל על המסר), hypermedia כמנוע של מצב האפליקציה.
* קוד על פי דרישה, השרת יכול להרחיב את הקוד בלקוח באמצעות שליחת קוד הכולל לוגיקה עסקית לביצוע בלקוח. הרחבה זו יכולה להיעשות באמצעות טכנולוגיות כגון: יישומונים ו-JavaScript. האילוץ האחרון הוא למעשה יכולת ולא מגבלה ואין חובה לעשות בו שימוש.

REST לעומת SOAP
---------------

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

התפיסה של REST מבוססת על שימוש במונחים ובמאפיינים קיימים בתוך פרוטוקול HTTP להגדרת אינטראקציה בין שרת ולקוח, כגון: headers לפניות (Requests) ולתגובות (Responses), ופורמטים של קבצים באינטרנט (Internet media types). לעומת זאת התפיסה ב-SOAP מבוססת על מאפיינים ומבנים ייעודיים ל-SOAP. הנגזרות של הבדל עקרוני זה הן צריכת משאבים נמוכה יותר בשימוש ב-REST מעל HTTP בהשוואה לצריכת המשאבים בשימוש ב-SOAP תחת HTTP וקלות בקידוד מהות הפניות והטיפול בתגובות תחת REST.

RESTful Web Service הוא Web Service פשוט המיושם באמצעות שימוש ב-HTTP ובעקרונות של REST.

להגדרה של RESTful Web Service יש שלושה מרכיבים:

1. ה-URI הבסיסי של ה-Web Service, למשל:
2. סוג ה-MIME של הנתונים. במקרים רבים הוא: XML, YAML או JSON.
3. אוסף הפעולות הנתמכות על ידי ה-Web Service במונחים של HTTP Methods, כגון: GET, POST, PUT, DELETE.

דוגמאות לשימוש ב-REST
---------------------

בשנים האחרונות נעשה שימוש נרחב ב-REST בהקשרים של יישומי ווב 2.0 ובמימוש Web Services ו-SOA. להלן מספר דוגמאות לשימוש בו:

* ATOM - פרוטוקול המשמש לצורך מנוי למעקב אחר שינויים באתר אינטרנט בדומה ל-RSS.
* Azure - מימוש מחשוב ענן של מיקרוסופט מבוסס על REST, XML ו-HTTP.
* שירותי מידע ב-WCF של חברת מיקרוסופט.
* מנגנון ה-API של מחשוב ענן של חברת סאן.
* מסגרות עבודה בסביבת PHP כגון: ZEND Framework
* Ruby on Rails
* מסגרות עבודה בסביבת Perl כגון: Catalyst Rest.
* בטכנולוגיית MVC 4 תוך שימוש ב-API

ראו גם
------

* Ruby on Rails
* SOAP
* HTTP
* Web Service
* Windows Azure
* Web 2.0

קישורים חיצוניים
----------------

* "Roy T. Fielding: Architectural Styles and the Design of Network-based Software Architectures"
* "Stefan Tilkov: A Brief Introduction to REST"
* "Stefan Tilkov: Addressing REST Doubts"
* "Stefan Tilkov: REST Anti-Patterns"
* "Gregor Roth: RESTful HTTP in practice"


|  |  |
| --- | --- |
| בקרת זהויות עריכת הנתון בוויקינתונים | 
* NLI: 987007549941105171
* GND: 7592728-7
* LCCN: sh2009000706

 |