בנייה נכונה של API לעריכת ישות עם כמה ישויות קשורים

[OdedDvir]

@yossiz אני מנסה להבין לאן אתה חותר. ברור לי שאין צורך לומר לך פוק חזי וכו' ואתה מכיר את הדרך המקובלת של RESTful API, על כל היתרונות והחסרונות שלה...
שמא אתה מחפש דרך יעילה ואלגנטית יותר לבצע עדכונים היררכיים ב-API, בסגנון של GraphQL?

[dovid]

@OdedDvir כתב בבנייה נכונה של API לעריכת ישות עם כמה ישויות קשורים:

פוק חזי וכו' ואתה מכיר את הדרך המקובלת של RESTful API

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

[dovid]

@OdedDvir עוד יש להעיר, REST לא נועד לשרת צד לקוח סופי אלא שכבת אפליקציה שהיא מקבל הוראות מצד לקוח (כי הוא לא נועד למקרים של אימות והרשאות וכולי).
אז אפשר להיתמם ולראות את שאלתו של יוסי כשאלה על הנדסת התקשורת הנכונה בין שכבת האפליקציה לצד לקוח הסופי.

[OdedDvir]

@dovid אתה מתכוון שהשאלה היא כיצד לעצב את חווית המשתמש בעריכה של נתונים היררכיים? מהניסוח של @yossiz הייתי תחת הרושם שכוונתו לדון על העיצוב המומלץ לשכבת API בצד השרת, אבל כעת אני מבולבל עוד יותר... למה התכוון המשורר?

[dovid]

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

[yossiz]

@OdedDvir כתב בבנייה נכונה של API לעריכת ישות עם כמה ישויות קשורים:

ברור לי שאין צורך לומר לך פוק חזי וכו' ואתה מכיר את הדרך המקובלת של RESTful API,

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

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

בהחלט הייתי מעדיף

[yossiz]

@OdedDvir כתב בבנייה נכונה של API לעריכת ישות עם כמה ישויות קשורים:

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

אם אתה כבר מזכיר את זה, יש לי שאלה נוספת שחשבתי לפתוח עליה עוד נושא ש-GraphQL הוא פתרון גם לזה. השאלה הוא לגבי דפים ב-UI שכל אחד יש לו שגעון אחר, אחד רוצה JOIN של טבלה א' ואחד של טבלה ב' וג' וכו, איך מטפלים בזה? אולי באמת אפתח לזה נושא חדש

[OdedDvir]

@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

ולשאלתך, דוד כבר ענה לך שלפי הספר הדרך היא ב.

[chagold]

https://dzone.com/articles/graphql-vs-rest

[yossiz]

@OdedDvir תודה על ההשקעה!
לענות על השאלה המקורית, אני מוודא שהבנתי אותך נכון: אתה טוען שב-API מבוסס REST כל בקשה אמור להתייחס לישות יחיד לבד?

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

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