בנייה נכונה של 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 שנועדו עבור דברים בסדר גודל של האינטרנט, מספיק לי ארכיטקטורה שיעבוד טוב עבור אפליקציה בסדר גודל שלי
