סטודנטים/ות יקרים/ות!

הפוסט הנ"ל הינו סיכום קצר של השיעור בנקודות + מכיל את הקבצים שתורגלו בכיתה במהלך השיעור.
אם החומר לא מובן, אפשר לשלוח לי מייל או להתקשר : 050-555-6693 (אשתדל לענות, אם לא שלחו SMS ואחזור אליכם)

זכרו כי המפתח להצלחה הינו תרגול

שיעור 54 – MVC – API

שלום לכולם, השיעור למדנו את הדברים הבאים:

MVC –תבנית עיצוב, דרך לתכנן קוד של אפליקציה

מכילה 3 חלקים עיקריים:

Model

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

View

תצוגה – למשל HTML

Controller –

מחבר בין המודל ל view, ממש לוגיקות

API:

http verbs:

GET

בקשה לקבל מידע.

בקשה זו מתבצעת שנכנסים לכתובת url מהדפדפן.

בבקשה זו נוכל לראות את הפרמטרים עוברים ב URL.

בבקשה מסוג GET  – אין BODY

POST

בקשה לשמירת מידע /הוספה של רכיב חדש.

למשל : רישום משתמש חדש לאפליקציה.

בבקשה זו הפרמטרים עוברים בגוף הבקשה – BODY

PUT

לערוך מידע קיים.

למשל – שינוי שם משתמש או שינוי סיסמה של משתמש קיים.

הנתונים נשלחים בגוף הבקשה.

DELETE

בקשה למחיקת אלמנט מהמערכת

למשל מחיקת משתמש ממסד הנתונים.

PATCH

עדכון של מספר רכיבים ביחד.

 

מבנה פונקציות מינימאלי ב API לניהול מוצרים

GET –

GET ALL – GET ALL DATA

GET BY ID – GET Product BY ID

POST –

AddProduct (product object)

Return new product

Put –

editProduct (id, object)

return new product

Delete

deleteProduct(id)

 

פעולות שנבצע בSQL בהתאם לבקשות –

GET – SELECT

POST – INSERT

PUT  – update

Delete – delete

 

POPULAR HTTP STATUS CODE:

200 – 299 :  –  תגובות הצלחה:

למשל:

200  – הבקשה הצליחה

201 – הבקשה הצליחה, ונוצר משאב חדש.

202 – הבקשה הצליחה וטרם נענתה

300-399 – הפניות:

301 – השרת החליף כתובת (מבוצע הפניה)

302 – הכתובת התחלפה

400-499 – תקלות שמגיעות מצד הלקוח

400 – הבקשה לא חוקית

401 – לא מאומת

403 – השרת כן מכיר את המשתמש, אבל המשתמש מבצע פעולה שאין לו הרשאה לבצע

404 – השרת לא מוצא את המשאב/דף המבוקש

405 – השרת מבין את הבקשה אבל כרגע לא ניתן להשתמש בה.

 

500-599 – תגובות של שגיאת שרת

500 – internal server error –

השרת נתקל בבעיה ואינו יודע מה המקור שלה ואיך לטפל בה.

501- השיטה לא נתמכת על ידי השרת

502 – Bad gateway –

פעולה לא מורשית/השרת לא מאפשר את הבקשה

504-  time out

 

צורות עבודה באפליקצית ווב :

 

SSR – SERVER SIDE RENDER –

השרת מקבל בקשה, מכין את קוד ה  HTML ושולח אותו לקליינט

 

CLIENT SIDE RENDER – למשל כמו ב SPA- single page application

בבקשה הראשונה לשרת – השרת מחזיר את קבצי ה HTML

ו js של האפליקציה.

ולאחר מכן, בכל קריאה השרת מחזיר JSON

ובעצם ה HTML  נבנה בצד הלקוח ע"י ה JAVASCRIPT  בצד הלקוח.

 

 

בהמשך השיעור התחלנו ליצור API באמצעות C#

קבצי השיעור להורדה

 

 

סגירת תפריט