הו-נתונים! (Odata)

אם אתם מתכננים לבנות מערכת על פי עקרונות ה REST, הפופולאריים למדי היום, כדאי להכיר עוד כמה כלים שיכולים לעזור במלאכה. אני מניח שאתם מכירים באופן כללי מהו REST. אם לא, תוכלו לקרוא פוסטים קודמים המספקים סקירה טובה כאן (מבוא) וכאן (קצת יותר לעומק). REST בפני עצמו פותח מרחב עצום של אפשריות מימוש. באיזה דרך אתם תבחרו? האם תתקלו בבעיות שאחרים נתקלו בהן כבר? איך תדעו שאתם לא נופלים ל pitfall נפוץ? איך תדעו שמה שעשיתם הוא טוב? איך??

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

מקור: http://everythingsdynamic.blogspot.com

בשרשרת פוסטים זו אדבר על ODATA (קיצור של Open Data) שנראה כיום התקן המבטיח להחלפת נתונים בין מערכות ברשת, המבוסס על עקרונות ה REST. התקן פשוט לשימוש פשוט, אך יש בו גם כמה מורכבויות. הוא מתאים בעיקר למצבים בהם הנתונים אותם אתם חושפים הם מורכבים ו/או יש לכם מספר צרכנים עם צרכים שונים. אם אתם זקוקים ל 3 שאילתות קבועות בין 2 מערכות - ODATA יהיה overkill בשבילכם. פשוט שלחו XML (או JSON) על גבי HTTP וטפלו בכמה שגיאות נפוצות.

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

אתחיל ב Atom Publishing Protocol (או בקיצור AtomPub, נקרא גם APP - אך זהו שם מבלבל) - תקן שנוצר עבור פרסום נתונים של בלוגים או אתרי חדשות וזכה לאימוץ ע"י מערכות מתחומים שונים לחלוטין.

גוגל, אחת המאמצות, ראתה שהתקן לא מספיק ושכל מוצר שלה (Calendar, Documents, Gmail) יצר כמה תוספות. היא אספה את התוספות השונות, סידרה אותן ויצרה את GDATA פרוטוקול מורחב המבוסס על AtomPub. לרוע המזל GDATA לא היה בשל כ"כ והיו בו מספר בעיות משמעותיות, אך עם הזמן גוגל מעדכנת ומשפרת את התקן. נדבר גם עליו.

מייקרוסופט, אחת הפטרוניות המרכזיות של תקני ה WS-* (תקני ה Web Services, אשר REST בא להחליפו) ראתה את התקנים שלה נזנחים ע"י חלקים הולכים וגוברים של התעשייה ולא רצתה להשאר מחוץ לתמונה. היא יצרה תקן בשם ODATA עליו נדבר. היא הבינה שהיא הצטרפה לחגיגה קצת מאוחר. בצעד חריג, עבור מייקרוסופט, היא פתחה את התקן ושחררה ספריות בג'אווה, ג'אווהסקריפט, PHP ועוד המאפשרות להשתמש בו. יש גם דיבורים על מסירת התקן לגוף תקינה חיצוני ובלתי תלוי - אך זה עדיין לא קרה.

כמובן שיש עוד שחקנים: יאהו מנסה לקדם תקן בשם DataRSS (ללא הצלחה רבה) וה W3C מנסה לקדם תקן בשם Linked Data המבוסס על פורמט בשם RDF - אך נכון להיום התקן שתופס הכי הרבה תאוצה הוא דווקא ODATA של מיקרוסופט והוא מאומץ גם ע"י חברות אינטרנט (נטפליקס, איביי) וגם ע"י ארגוני ענן (יבמ, סאפ).


ODATA
OData הוא קיצור ל Open Data Protocol. אם מחפשים עליו חומר כדאי לשים לב ש Open Data הוא מושג רעיוני של שיתוף מידע באינטרנט. חפשו ODATA או Open+Data+Protocol כדי לקבל תוצאות טובות יותר.

OData פועל על גבי HTTP ומבוסס על עקרונות ה REST. בעצם הוא מבוסס על AtomPub שמבוסס גם על Atom וגם על REST. מבולבלים? הנה לנוחיותכם דיאגרמת Venn שתסביר את העניין:

• POX הוא הרעיון של העברת נתונים על גבי HTTP בפורמט XML (כלשהו).
• REST היא ארכיטקטורה מבוססת Resources המבוססת על POX, אך מציבה חוקים נוספים => כלומר, מקרה פרטי של POX. הסתייגות קטנה היא ש REST לא מחייב XML.
• Atom הוא פורמט מבוסס XML לתיאור Web Feed - רשימת פריטי חדשות, פוסטים בבלוג וכו'. הפורמט המקביל והמוכר קצת יותר הוא RSS.
• AtomPub הוא מימוש REST המבוסס על פורמט ה Atom שמאפשר לא רק לקרוא Web Feeds אלא גם להוסיף / לעדכן ולמחוק אותם. הוא מוסיף גילוי ועוד כמה יכולות. 
• ODATA (כמו GDATA) מבוסס על AtomPub (ומכאן גם על Atom) ומספק סט כלים עשיר יותר של כלים.

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

ODATA לוקח את הדברים צעד אחד הלאה:

• מרחיב מעט את המודל של אטום ומגדיר טיפוסים (דבר שמסייע לתקשורת עם צד השרת)
• מאפשר להשתמש ב JSON במקום XML (פורמט רזה יותר) 
• מאפשר לבצע שאילתות מורכבות על הנתונים
• מגדיר מודל אבטחה ו Authentication
• עוזר לטפל במקביליות

אציין שפרוטוקול GDATA חופף ל ODATA בהבטים רבים - אך הוא נראה פחות מגובש ומובנה.

דמיינו בנפשכם שיש לכם מספר אפליקציות ווב (או מובייל) שזקוקות לשלוף נתונים מהשרת. האם עבור כל אפליקציה תמציאו התנהגות שונה של התקשורת? מודל סנכרון או אבטחה? קונבנציה לשאילתות על הנתונים?
הרבה יותר פשוט הוא לעבוד עם קונבנציה אחידה לכל האפליקציות, כאשר כל אפליקציה, כמובן, חושפת את האובייקטים שלה והפעולות האפשריות עליהם. בדרך זו תחסכו זמן פיתוח, איתור בעיות תכנוניות, זמן למידה של התנהגות של כל אפליקציה או סתם context-switch מבלבל בין מערכת חוקים אחת לשנייה. זהו התמורה העקרית של פרוטוקולים אלו ובעיקר ODATA (מכיוון שהוא שלם יותר וסביר פחות שתזדקקו להרחיב ולהמציא מסביבו פתרונות).

באופן דיי מפתיע אין כמעט חומר על אף אחד מהפרוטוקולים האלו מלבד התיעוד הרשמי וכמה מצגות באינטרנט. לא מצאתי ספרים או תיעוד לימודי מסודר על אף אחד מהפרוטוקולים, מלבד ODATA שיש לו תיעוד לכל-היותר סביר. ייתכן ואני אספק פה מידע דיי יחודי ;-)

בפוסט ההמשך אדבר על AtomPub וכיצד אפשר להשתמש בו למימושי REST פשוטים