Куда приходит HTTP-запрос от клиента в веб-приложении?

А, ну это же классика, про которую все вроде знают, а потом на собеседовании просят нарисовать и нихуя не могут вспомнить, кроме Kestrel и контроллера. Ёпта, давайте по косточкам разберём, как этот цирк с конями на самом деле работает.

Представь, что твой HTTP-запрос — это какой-нибудь Вася Пупкин, который пришёл в огромную контору «Рога и Копыта.NET» за справкой. Вот его путь, полный унижений и бюрократии.

1. КПП (Веб-сервер: Kestrel/IIS/Nginx). Вася подходит к воротам. Там сидит сторож-сервер, обычно это наш кроссплатформенный дружок Kestrel. Его задача — проверить, не несёт ли Вася с собой гранату (невалидные данные), и впустить его на территорию. «Документик?» — «Вот мой HTTP-запрос, заголовки, всё как надо». — «Проходи, следующий».

2. Конвейер бюрократии (Middleware). Попав внутрь, Вася не идёт сразу к директору. Его гоняют по всем кабинетам. Это и есть конвейер middleware, который ты настраиваешь в Program.cs. Каждый middleware — как отдельный клерк, который делает свою мелкую, но важную хуйню.

app.UseHttpsRedirection(); // Клерк №1: хватает Васю за шкирку. «Ты чё, по HTTP пришёл? Иди обратно и зайди по HTTPS, безопасность, блядь!»
app.UseStaticFiles();      // Клерк №2: смотрит, не за справкой ли о статическом файле (картинка, css). «А, тебе favicon.ico? На, держи и проваливай, не задерживай очередь».
app.UseAuthentication();   // Клерк №3 (Отдел кадров): «Вася, твой пропуск (куки/token) где? Кто ты вообще такой?»
app.UseAuthorization();    // Клерк №4 (Служба безопасности): «Так, Вася, пропуск есть. А тебе в кабинет к гендиру (к админ-методу) вообще можно? Нет? В жопу отсюда!»
app.UseRouting();          // Клерк №5 (Справочное бюро): «Твоя конечная цель? А, тебе в отдел «API/Users». Сейчас направлю».

Вася идёт по этому коридору, и если на каком-то этапе его посылают нахуй (например, авторизация не прошла), то он идёт обратно тем же путём, но уже с позорной бумажкой «401 Unauthorized».

3. Маршрутизация (Endpoint Routing). Клерк из справочного (UseRouting) смотрит в свою толстую книгу правил (таблицу маршрутов) и понимает: «Ага, путь у тебя /api/users/5 и метод GET. Значит, тебе к Ивану Иванычу в кабинет 305, он заведующий отделом UsersController, метод GetUser».

4. Конечный исполнитель (Endpoint). Вот Вася, наконец, дошёл до нужной комнаты. Там сидит тот самый Иван Иваныч (обработчик endpoint) и делает полезную работу. Это может быть:

• Современный хипстер-разработчик (Минимальный API): Сидит в open-space, всё быстро-быстро.

  app.MapGet("/api/users/{id}", (int id) => {
      // Полезная работа: сходить в БД, найти юзера.
      // Если не найден — «Вася, иди нахуй, нет такого» (return Results.NotFound()).
      return Results.Ok(user); // Нашёл — вот тебе справка в JSON.
  });

• Солидный начальник отдела (Контроллер MVC/Web API): Сидит в кабинете с кожаным креслом.

  [ApiController]
  [Route("api/[controller]")]
  public class UsersController : ControllerBase
  {
      [HttpGet("{id}")] // Висит табличка на двери «Только GET-запросы с ID»
      public IActionResult GetUser(int id) {
          // Тут тоже идёт полезная работа, но с большим чувством собственной важности.
          return Ok(user); // Подписывает бумагу и ставит печать.
      }
  }

5. Путь назад с результатом. Иван Иваныч выдал Васю результат (или отказ). Вася с этой бумажкой идёт обратно по тому же самому коридору middleware, но уже в обратном порядке. Каждый клерк может что-то своё поделать: логгер — записать, что Вася ушёл, middleware для добавления заголовков — прицепить какую-нибудь печать X-Powered-By: ASP.NET.

И наконец, Вася выходит через те же ворота (Kestrel), который отдаёт ему итоговый HTTP-ответ. Всё, справка получена, Вася доволен.

Вот и вся магия. Если где-то в цепочке ебучка — например, в БД коннект проёбан — то исключение летит наверх, и, если не поймано, Вася получает не справку, а бумажку «500 Internal Server Error», то есть ему просто выносят мозг у ворот. Красота.