בנייה נכונה של API לעריכת ישות עם כמה ישויות קשורים
-
יש אפליקציה (וובית) שנותן לערוך ישות מסויים, בוא נקרא לו "אבא". כל "אבא" משוייך לכמה בנים, יש דרישה שיהיה טופס אחד לערוך את האבא עם כל הבנים כולל אפשרות להוסיף בנים ולמחוק (לרצוח?) אותם.
השאלה איך הכי נכון לבנות דבר כזה:
א. בצד שרת יהיו רק APIs הגיוניים: לכל ישות endpoint משלו, ובעת שמירה, צד הלקוח יקרא בזה אחר זה (או במקביל) לכל ה-endpoint-ים, כלומר לחצן אחד יגרום לכל הפעולות הבאות: "ערוך את האבא", "מחק בנים אלו", "ערוך בנים אלו", "הוסף בנים אלו"
ב. צד הלקוח יחייב שמירה בנפרד לכל ישות, אין שמירה של אבא-עם-הבנים על אף שאפשר לערוך את הכל בטופס אחד
ג. בצד שרת יהיה endpoint נוסף שמטפל בעריכת-אבא-עם-בניו
ד. הדרישה בכלל טפשית וצריך לשכנע את הדורש שזה לא נכון(אני קצת מערב פה שיקולים של UX ושיקולי הנדסת תוכנה)
-
@yossiz א-ג הם הנכונים.
ב הגיוני רק במקרים בהם חשוב שהמשתמש יבין מה שקרה (זה אמור להיות מקרים נדירים ביותר, במשתמשים+פעולות מאוד טכניות גם בתפישה של המשתמש, וגם על זה ניתן להתגבר עם UX מוצלח).
ד ודאי לא נכון, זה דרישה אולטרה לגיטימית לפחות במקרים שאני מדמיין בראשי.מתוך א, וג.
א הוא הנכון לפי הספר, וגם בעצם מקל את התחזוקה בשני הצדדים. כי גם בצד הלקוח לא עובדים עם JSON שמייצג גרף מסובך אלא עובדים צעד אחרי צעד, כל שגיאה נמצא במקום מאוד מסויים הן בצד לקוח והן בצד שרת.
(גם לפי הא', צריך לאפשר bulk לדעתי לאוסף מאותו סוג כמו עריכת בנים ולא עריכת בן, כי זה שינוי קטן בצד השרת והפחתת תקורת בקשות בצד הלקוח).
למרות כל זאת, אני כמעט תמיד פועל כמו ג, כי זה מאפשר פיתוח מהיר בהרבה. אצלי יהיה endpoint אחד ויחיד שייקרא "עריכת-אב" והוא יטפל א. עריכת אב קיים ב. עריכת אב חדש, ג. הסרת בנים מהאב ד. הוספת בנים לאב.
בדוטנט אני יעשה זאת עם מחלקת אב שיש לה מאפיין אוסף לבנים, ומאפיין אוסף נוסף לבנים למחיקה. כל אלמנט (אב או הבנים) ללא ID, זה אלמנט להוספה, כל אחד יש לו ID זה אלמנט לעריכה.
(באלמנט לעריכה טוענים עותק מהמסד ועושים עדכון לכלל המאפיינים ברי העדכון (או חיפוש הבדלים מעצבן אם על הדרך מתעדים שינויים, מנסיוני זה פעולה קלה יותר בצד לקוח ואז שולחים טבלת שינויים ישות,מזהה,מאפיין,ערך ישן [לוידוא אי התנגשויות], ערך חדש). -
@dovid
גילוי נאות: כבר החלטתי מראש איזה תשובה אני רוצה לשמוע...
ענית בדיוק מה שלא רציתי לשמוע (מה שכתבת ש"אצלי יהיה endpoint אחד ויחיד שייקרא "עריכת-אב" זו האופציה הכי גרועה בעיני ואפילו לא העליתי את זה כצד)דעתי:
ד עדיף עבור נוחות הפיתוח ופשטות הקוד, אבל לפעמים הדרישה הגיונית או שהלקוח מתעקש
בעדיפות שנייה הייתי עושה את ב, גם מטעמי פשטות, אבל גם כאן צריך לקחת את דרישות הלקוח בחשבון
במקרה הצורך אני אוהב את ג על פני א אבל שיהיה בפירוש endpoint נוסף שקיים רק בשביל ה-UI הספציפי הזה. ל-endpoint הזה יש לשלוח 4 דברים: אבא, בנים להוסיף, בנים למחוק, ובנים לעדכן. הלוגיקה שמפצל את הבנים לשלושת החלוקות שאתה עושה בצד שרת, שייעשה בצד לקוח.
א נשמע לי קצת מוגזם אבל זה דומה מאוד לג' רק שזה יהיה endpoint אחד ולא ארבעאשמח לשמוע עוד דעות, או טענות/שיכנועים למה אני לא צודק
-
@yossiz
אשמח לדוגמא אמיתית
במה מאפיין את ישות הבן כבן?במקרה של אחים (שלפעמים מקושרים) שלחתי קריאות נפרדות, סתם בגלל הפשטות, ובגלל שלפעמים עושים מניפולציה שונה (בצד הלקוח) על חלק מהקריאות, וגם בגלל שבין כה הצגתי חיוויי ברור בצד הלקוח.
בחשיבה מחדש, הייתי כנראה מגדיר ב-API אפשרות לקבל מערך וכך הוא גנרי. -
@אהרן כתב בבנייה נכונה של API לעריכת ישות עם כמה ישויות קשורים:
z
אשמח לדוגמא אמיתית
במה מאפיין את ישות הבן כבן?נגיד שיש לך בית דפוס, אז יש לקוחות ולכל לקוח יכול להיות כמה הזמנות ולכל הזמנה כמה פריטים, הפריטים הם בנים של הזמנות והזמנות הם בנים של לקוח
-
-
@OdedDvir כתב בבנייה נכונה של API לעריכת ישות עם כמה ישויות קשורים:
פוק חזי וכו' ואתה מכיר את הדרך המקובלת של RESTful API
זה סתירה באותו משפט.
REST נעשה נכון רק בויקיפדיה (בתיאור הערך, לא בAPI שלהם) ובצדק... עמא נוהג לעשות מלא בלגנים. -
@OdedDvir עוד יש להעיר, REST לא נועד לשרת צד לקוח סופי אלא שכבת אפליקציה שהיא מקבל הוראות מצד לקוח (כי הוא לא נועד למקרים של אימות והרשאות וכולי).
אז אפשר להיתמם ולראות את שאלתו של יוסי כשאלה על הנדסת התקשורת הנכונה בין שכבת האפליקציה לצד לקוח הסופי. -
-
@OdedDvir כתב בבנייה נכונה של API לעריכת ישות עם כמה ישויות קשורים:
ברור לי שאין צורך לומר לך פוק חזי וכו' ואתה מכיר את הדרך המקובלת של RESTful API,
האמת שאני לא מכיר, זה לא נושא שלמדתי בצורה מסודרת אף פעם
אולי תרצה לגלות לי מה יש ל-REST להגיד במקרה שלי?
אם היית שואל אותי, הייתי עונה בבורותי שאין לו מה להגיד בנושא הזה וזה לא עניינו
אשמח אם תכתוב בפירוש מה התשובה לפי פילוסופיית ה-RESTשמא אתה מחפש דרך יעילה ואלגנטית יותר לבצע עדכונים היררכיים ב-API, בסגנון של GraphQL
בהחלט הייתי מעדיף
-
@OdedDvir כתב בבנייה נכונה של API לעריכת ישות עם כמה ישויות קשורים:
שמא אתה מחפש דרך יעילה ואלגנטית יותר לבצע עדכונים היררכיים ב-API, בסגנון של GraphQL
אם אתה כבר מזכיר את זה, יש לי שאלה נוספת שחשבתי לפתוח עליה עוד נושא ש-GraphQL הוא פתרון גם לזה. השאלה הוא לגבי דפים ב-UI שכל אחד יש לו שגעון אחר, אחד רוצה JOIN של טבלה א' ואחד של טבלה ב' וג' וכו, איך מטפלים בזה? אולי באמת אפתח לזה נושא חדש
-
@yossiz אני גם לא למדתי את הנושא באופן מסודר, ומסתפק אם יש לי מה להוסיף לך בנושא, אבל כיון שביקשת:
בקצרה, RESTful API הוא סגנון עיצוב של ה-API בצורה [השואפת ל]כך שבקשות ה-HTTP שנשלחות אל ה-API יבצעו פעולה בהתאמה לסוג המתודה של הבקשה (HttpMethod), למשל:
POST ליצירה
GET עבור קריאה
PUT עבור עדכון
DELETE עבור מחיקהוכן נקודות הקצה של ה-API יהיו במבנה מאורגן, בד"כ היררכי לפי סוג ישות\מזהה:
GET Users GET Clients/123 DELETE Doctors/456ויחזירו קודים מובנים, כמו
200עבור success ו-404עבור not found.
כך שה-API אמור להיות אינטואיטיבי.ב-CRUD פשוט הכל טוב ויפה, עד שמגיעים לפעולות קצת יותר מורכבות, בהם לא ברור כל כך איך להיות RESTful "טהור".
לדוגמא: עדכון חלקי של רשומה (מישהו אי פעם השתמש ב-PATCH ?), שיוך ישות-צאצא לישות-אב (האם הנתיב של פעולת שיוך מטופל לרופא, צריך להיות PUT Doctors/1/Patients/4 או אולי PUT Patients/4/Doctors/1 ?)כיוון ש-REST הוא לא ממש סטנדרט, כמו ש@dovid הזכיר, הכאוס חוגג וכל אחד מעקם את הכללים כרצונו, מתכנת מתחיל יכול ליצור API endpoints מוזרות, כמו:
POST Doctors/delete?doctorid=123 GET Doctors/all GET Doctors/2/deleteולשאלתך, דוד כבר ענה לך שלפי הספר הדרך היא ב.
-
@OdedDvir תודה על ההשקעה!
לענות על השאלה המקורית, אני מוודא שהבנתי אותך נכון: אתה טוען שב-API מבוסס REST כל בקשה אמור להתייחס לישות יחיד לבד?אני גם מתרשם כך, אבל עקרונות REST לא נהירים לי מספיק
זה לא מענין הנושא לדון על REST, אבל נראה לי שיש מרחק בין מה שנהוג לקרוא REST לבין העקרונות האמיתיים של REST.בכל מקרה, אין לי ענין מיוחד לעבוד דוקא לפי עקרונות REST שנועדו עבור דברים בסדר גודל של האינטרנט, מספיק לי ארכיטקטורה שיעבוד טוב עבור אפליקציה בסדר גודל שלי
