# HTTP — Request, Response וקודי סטטוס📖 שיעור

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

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

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

```bash
dotnet --version
```

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

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

```bash
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. מריצים:**

```bash
dotnet run
```

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

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

```csharp
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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview)

[MDN — HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status)

---

## תרגילים

### תרגיל 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 שלמדנו כאן לקוד אמיתי שמגיב לבקשות, שלב אחר שלב — כולל שלוש הדרכים השונות שבהן מידע מגיע לשרת (בתוך הכתובת, אחרי סימן שאלה, ובגוף הבקשה).