HTTP — Request, Response וקודי סטטוס

איך מתחילים — יצירת הפרויקט הראשון#

לפני שצוללים ל-HTTP עצמו, צריך פרויקט ASP.NET Core אמיתי שרץ על המחשב. ארבעה שלבים:

1. ודאו שה-.NET SDK מותקן:

dotnet --version

אם הפקודה לא נמצאת — יש להתקין את ה-.NET SDK (לא רק ה-Runtime) מהאתר הרשמי של מיקרוסופט.

2. יצירת פרויקט חדש:

dotnet new web -n MyFirstApi
cd MyFirstApi

dotnet new web יוצר את הטמפלט המינימלי — בדיוק הבסיס שכל הדוגמאות בשיעורי היחידה הזו בנויות עליו. (יש גם טמפלט webapi, עם Swagger מובנה ואפשרות ל-Controllers — נחזור אליו כשנגיע לשיעור ה-Controllers.)

3. הכירו את הקבצים שנוצרו:

• Program.cs — נקודת הכניסה וגם מקום ההגדרות כולן; בפרויקט מינימלי כזה, כל מה שנלמד ביחידה (Middleware, Endpoints, DI) נכתב כאן.
• appsettings.json / appsettings.Development.json — הגדרות תצורה (connection strings, מפתחות, וכו’) — הקובץ השני דורס את הראשון כשמריצים בסביבת פיתוח.
• Properties/launchSettings.json — איך המחשב שלכם מריץ את הפרויקט מקומית: איזה פורט, HTTP או HTTPS.
• bin/, obj/ — נוצרים אוטומטית בכל build; לא עורכים בהם דבר, ולא מוסיפים אותם ל-Git (.gitignore).

4. מריצים:

dotnet run

הפלט מדפיס את הכתובת שהשרת מאזין לה (למשל http://localhost:5xxx). זו הכתובת שאליה תישלחנה כל הבקשות מהדוגמאות בשיעור.

זו נקודת ההתחלה של כל שיעור ביחידה — Program.cs ריק לגמרי מלבד:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello, ASP.NET Core!");

app.Run();

פותחים דפדפן בכתובת שהודפסה ומוסיפים / — אם רואים Hello, ASP.NET Core!, הפרויקט רץ נכון וממשיכים לשיעור עצמו.

מה זה?#

כל פעם שאתם מקלידים כתובת אתר בדפדפן, או לוחצים על קישור, קורה משהו קבוע: הדפדפן שלכם (הוא ה"לקוח" — Client) שולח “מכתב” למחשב שמארח את האתר (הוא ה"שרת" — Server), והשרת שולח “מכתב תשובה” בחזרה. עד עכשיו כל התוכניות שכתבתם רצו לבד על המחשב שלכם — הן לא “דיברו” עם אף אחד. אפליקציית Web אמיתית חייבת לתקשר בין שני מחשבים שונים, לפעמים אפילו בקצוות שונים של העולם.

הבעיה: איך שני מחשבים, שאולי נכתבו על ידי אנשים שונים לגמרי, בשפות תכנות שונות לגמרי, יידעו “לדבר” בלי בלבול? HTTP הוא בדיוק הפתרון — פרוטוקול (כלומר: הסכם קבוע על איך “המכתבים” האלה חייבים להיראות), כדי שכל דפדפן וכל שרת בעולם, מכל חברה שכתבה אותם, ידעו להבין אחד את השני.

מילות מפתח שחשוב לזכור#

• HTTP Request (“הבקשה”) — ה"מכתב" שהלקוח שולח לשרת: מי שולח ולמה (Method), לאן בדיוק (URL), מידע נוסף על המכתב עצמו (Headers), ולפעמים תוכן מצורף (Body)

• HTTP Response (“התשובה”) — ה"מכתב חוזר" מהשרת: איך הבקשה הסתיימה (Status Code), מידע נוסף (Headers), והתוכן עצמו (Body — בדרך כלל JSON)

• HTTP Method (הפועל) — איזו פעולה מבקשים: GET (תנו לי לקרוא מידע), POST (צרו לי משהו חדש), PUT (עדכנו משהו קיים), DELETE (מחקו). בדיוק כמו בספרייה: GET = לשאול ספר, POST = להוסיף ספר חדש למדף, PUT = להחליף מהדורה ישנה בחדשה, DELETE = להוציא ספר מהמדף לצמיתות

• Status Code — התשובה מסוכמת במספר אחד, בדיוק כמו רמזור: ירוק (2xx) = הצליח, אדום-אשמתך (4xx) = אתה (הלקוח) עשית משהו לא תקין, אדום-אשמתנו (5xx) = קרתה תקלה אצלנו בשרת

GET /api/students/5 HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGc...

(No Body in GET — only requesting data, not sending any)

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 5, "name": "Dana", "age": 25}

POST /api/students HTTP/1.1
Host: example.com
Content-Type: application/json

{"name": "Avi", "age": 22}

--- Response ---
HTTP/1.1 201 Created
Content-Type: application/json

{"id": 6, "name": "Avi", "age": 22}

הסבר עיקרי#

אנטומיה של כתובת (URL)#

כשמסתכלים על כתובת כמו https://example.com/api/students, יש בה כמה חלקים קבועים: https:// הוא הפרוטוקול (איך מדברים), example.com הוא כתובת השרת (עם מי מדברים), ו-/api/students הוא ה"נתיב" (Path) — איזה משאב ספציפי באתר מבקשים. בשיעור הבא נלמד שיש גם דרך שלישית להוסיף מידע לכתובת (Query String), אבל את זה נשאיר לרגע שבו יהיה לו שימוש אמיתי.

למה יש כמה Methods שונים ולא אחד#

GET/POST/PUT/DELETE הם מוסכמה: GET תמיד רק קורא מידע (בלי לשנות כלום בשרת — “בטוח” לקרוא לו כמה פעמים בלי לפחד לשבור משהו); POST יוצר משהו חדש; PUT מעדכן קיים; DELETE מוחק. המוסכמה הזו (נקראת REST) מאפשרת לכל מפתח שמסתכל על DELETE /api/students/5 לדעת מיד מה קורה, בלי לקרוא תיעוד.

Status Codes מקובצים לפי משמעות#

2xx = הצלחה (200 OK, 201 Created); 4xx = שגיאת לקוח (400 Bad Request — קלט שגוי, 404 Not Found — לא קיים, 401 Unauthorized — לא מחובר); 5xx = שגיאת שרת (500 Internal Server Error — משהו נשבר בצד השרת). ההבחנה בין 4xx ל-5xx קריטית לדיבוג: 4xx אומר “הלקוח עשה משהו לא תקין”, 5xx אומר “השרת נכשל, לא באשמת הלקוח”.

Body מופיע רק בחלק מהבקשות#

GET לא שולח Body (רק מבקש מידע דרך ה-URL); POST/PUT שולחים Body (בדרך כלל JSON — קשור ישירות לשיעור ה-JSON מהיחידה הקודמת) עם הנתונים ליצירה/עדכון. Response כמעט תמיד מכיל Body עם התוצאה, פרט לתשובות ריקות כמו 204 No Content.

יתרונות#

HTTP הוא סטנדרט אוניברסלי — כל שפה, כל דפדפן, כל כלי (Postman, curl) יודעים “לדבר” אותו; Status Codes נותנים משמעות ברורה ומיידית בלי לפרש טקסט חופשי; Methods נותנים כוונה ברורה (GET=קריאה, DELETE=מחיקה) שקל להבין ולתעד.

חסרונות#

HTTP הוא Stateless (חסר-זיכרון) — כל בקשה עצמאית לגמרי, השרת לא “זוכר” בקשות קודמות מאותו לקוח בלי מנגנון נוסף (כמו Token, שיוזכר ביחידת Auth); Status Codes דורשים משמעת — קל “לזרוק” הכל כ-200 גם כשמשהו נכשל, מה שמטעה לקוחות.

נקודות חשובות#

• GET=קריאה, POST=יצירה, PUT=עדכון מלא, DELETE=מחיקה — המוסכמה הבסיסית של REST

• 2xx=הצלחה, 4xx=שגיאת לקוח, 5xx=שגיאת שרת — קטגוריות Status Code

• GET לא שולח Body; POST/PUT בדרך כלל כן, בפורמט JSON

• HTTP הוא Stateless — כל בקשה עצמאית, בלי זיכרון מובנה של בקשות קודמות

טעויות נפוצות#

• להחזיר 200 OK גם כשמשהו נכשל בפועל — מטעה את הלקוח שקורא רק את קוד הסטטוס

• לבלבל בין 401 (לא מחובר בכלל) ל-403 (מחובר, אך אין הרשאה) — משמעות שונה לגמרי

• לשלוח Body בבקשת GET ולצפות שהשרת יקרא אותו — לא חלק מהמוסכמה הסטנדרטית

סיכום#

HTTP הוא הפרוטוקול שמגדיר איך לקוח ושרת מתקשרים — Request עם Method/URL/Headers/Body אופציונלי, ו-Response עם Status Code/Headers/Body. ה-Methods (GET/POST/PUT/DELETE) נותנים כוונה ברורה לכל בקשה, ו-Status Codes (2xx/4xx/5xx) מסכמים את התוצאה במספר אחד קריא. זו השפה הבסיסית שעליה כל שאר ASP.NET Core ו-REST APIs נבנים.

דוקומנטציה רשמית#

MDN — HTTP overview

MDN — HTTP response status codes

תרגילים#

תרגיל 1 — זיהוי Method נכון#

המשימה: לכל אחת מהפעולות הבאות, כתבו את ה-HTTP Method הנכון: (א) קבלת רשימת מוצרים, (ב) הוספת מוצר חדש, (ג) מחיקת מוצר, (ד) עדכון מחיר מוצר קיים.

בדיקה: התשובות הן GET, POST, DELETE, PUT בהתאמה, עם נימוק קצר לכל אחת.

תרגיל 2 — זיהוי Status Code#

המשימה: לכל תרחיש, כתבו Status Code מתאים: (א) בקשה הצליחה ויצרה רשומה חדשה, (ב) הלקוח שלח JSON לא תקין, (ג) מוצר עם ID מבוקש לא קיים, (ד) חריגה בלתי-צפויה בשרת.

בדיקה: התשובות הן 201, 400, 404, 500 בהתאמה.

פרויקט מסכם#

המשימה: תכננו (על נייר/מסמך, ללא קוד עדיין) API בסיסי לניהול “משימות” (Tasks), עם כל ה-endpoints הדרושים.

דרישות:

1. הגדירו לפחות 5 endpoints שונים (Method + URL) לפעולות CRUD מלאות על משימות
2. לכל endpoint, ציינו Status Code מוצלח וStatus Code כישלון אפשרי אחד לפחות
3. תארו דוגמת Body (JSON) לבקשת יצירת משימה ולתשובה המתאימה

בדיקה: התכנון מכסה יצירה, קריאה (יחיד ורשימה), עדכון ומחיקה — כל אחד עם Method/URL/Status Codes נכונים לפי המוסכמות שנלמדו.

מה בפרק הבא#

בפרק הבא — CRUD בסיסי: הופכים את ה-Methods וה-Status Codes שלמדנו כאן לקוד אמיתי שמגיב לבקשות, שלב אחר שלב — כולל שלוש הדרכים השונות שבהן מידע מגיע לשרת (בתוך הכתובת, אחרי סימן שאלה, ובגוף הבקשה).