מה זה REST ומתי נשתמש בה?

 אז היום אנחנו ננסה לענות על השאלה מה זה REST?

ובכן, REST הם ראשי תיבות של REpresentational State Transfer שזו בעצם ארכיטקטורה למערכות מבוזרות שהוצגה לראשונה ע"י Roy Fielding בשנת 2000.

כמו כל ארכיטקטורה אחרת גם ל-REST יש את 6 ההגבלות המנחות שלה כדי שהמערכת שנבנה תזכה לתואר RESTful system.

  1. Client - Server: ע"י הפרדה של צד הלקוח והדאגה לכל מה שקשור לתצוגה, מניהול מערכות המידע של המערכת, אנחנו בעצם משפרים את יכולת הניידות של צד הלקוח וצד השרת לכל פלטפורמה וטכנולוגיה שנרצה.
    הדבר יביא למצב שאנחנו משדרגים את המדרגיות או בעברית יכולת הגדילה והצמיחה (Scalability) של המערכת בעתיד, ע"י הפרדה של צד הלקוח מצד השרת, כשכל אחד עצמאי להתפתח בכיוון שלו ובטכנולוגיות שקשורות לתחום שלו בלי תלות.

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

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

  4. Uniform interface: ע"י מימוש של כלל ההכללה בפיתוח תוכנה לממשק של המערכת, כל המערכת עוברת הפשטה ובעצם כל התקשורת בין הצדדים הופכת להיות ברורה ומשופרת. 
    על מנת לשמר את האחידות ברכיבים השונים של המערכת יש להחיל מגבלות כדי לשמר את ההתנהגות הצפויה של הרכיבים השונים במערכת.
    REST מוגדר באמצעות הצמדות ל 4 כללים כשבונים את הממשק של רכיבי המערכת - זהות של משאבים; ייצוג של השימוש במשאבים השונים; הודעות שמסבירות את עצמן באופן מפורש; 
    Hypermedia as the Engine of Application State  שזה בצורה מופשטת אומר, שימוש בלינקים כדי להעביר מסרים בין הלקוח לשרת בצורה דינמית, או במילים אחרות (HATEOAS) 
    דוגמא תסביר את זה בצורה טובה יותר:
    לקוח - שלח לי בבקשה את פרטי החשבון של הלקוח בפורמט של JSON 
    GET /accounts/12345 HTTP/1.1
Host: bank.example.com
Accept: application/vnd.acme.account+json
...

    שרת - אין בעיה אחי, אלה פרטי החשבון ואלה הפעולות שאתה יכול לבצע
      (הפקדה\משיכה\העברה\סגירה)
    HTTP/1.1 200 OK
Content-Type: application/vnd.acme.account+json
Content-Length: ...

{
    "account": {
        "account_number": 12345,
        "balance": {
            "currency": "usd",
            "value": 100.00
        },
        "links": {
            "deposit": "/accounts/12345/deposit",
            "withdraw": "/accounts/12345/withdraw",
            "transfer": "/accounts/12345/transfer",
            "close": "/accounts/12345/close"
        }
    }
}
    לקוח אחרי כמה שעות - שלח לי בבקשה את פרטי החשבון של הלקוח בפורמט של JSON
     שרת אחרי כמה שעות - אין בעיה אחי, אלה פרטי החשבון והפעם בגלל שהחשבון במינוס, אלו הפעולות שאתה יכול לבצע בחשבון
    (הפקדה)

    HTTP/1.1 200 OK
Content-Type: application/vnd.acme.account+json
Content-Length: ...

{
    "account": {
        "account_number": 12345,
        "balance": {
            "currency": "usd",
            "value": -25.00
        },
        "links": {
            "deposit": "/accounts/12345/deposit"
        }
    }
}
  5. Layered system: הארכיטקטורה בסגנון של מערכת רבודה הבנויה משכבות שכבות מונעת מכל שכבה לראות ולדעת מה יש מעבר לה בשכבות האחרות שאיתה היא באה במגע

  6. Code on Demand: אריכטקטורת REST מאפשרת לצד הלקוח להרחיב את היכולות שלו ע"י הורדה ושימוש בקוד בתצורה של סקריפטים.
    זה מפשט את השילוב של הלקוח והשרת מבחינת הצורך בהתקנות והכנות מראש.

לסיכום

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

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

תגובות

הוסף רשומת תגובה