Словарь веб-разработчика

Headless CMS — система управления контентом без встроенного фронтенда («головы»). Контент хранится и редактируется в CMS, но отдаётся через API (REST или GraphQL), а отображение полностью контролирует разработчик. Headless vs Traditional CMS Traditional (WordPress, Drupal) — CMS рендерит HTML. Фронтенд и бекенд жёстко связаны Headless — CMS только управляет контентом и отдаёт API. Фронтенд — любой: React, Vue, мобильный, digital signage Преимущества Один контент → несколько каналов (веб, мобильный, IoT) Свобода в выборе технологий фронтенда Лучшая производительность — статический фронтенд + CDN Популярные Headless CMS SaaS: Contentful, Sanity, Strapi (self-hosted), Directus (self-hosted), Prismic. Git-based: Netlify CMS, Tina CMS — контент в Git-репозитории.

Health Check — endpoint или механизм, позволяющий внешней системе (балансировщик, оркестратор) проверить, готов ли сервис обрабатывать запросы. Если сервис «нездоров» — его исключают из ротации.ТипыLiveness — жив ли процесс? Если нет — перезапустить. Просто: GET /up → 200 OKReadiness — готов ли принимать трафик? Проверяет соединения с БД, Redis, зависимостями. Если нет — исключить из балансировщика, но не перезапускатьStartup probe — дополнительное время при старте (долгий bootstrap)Что проверять в readinessСоединение с БД (ping)Соединение с RedisКритические внешние сервисыДостаточно свободной памяти и дискового пространстваФормат ответаGET /health → 200 {"status":"ok","db":"ok","redis":"ok"} → 503 {"status":"degraded","db":"error"}

Stack и Heap — два региона памяти, используемых программами по-разному. Понимание их помогает диагностировать утечки памяти и stack overflow. Stack (стек вызовов) Автоматически управляемая память для локальных переменных и call frames. При вызове функции её данные добавляются в стек. При возврате — удаляются. Stack overflow = рекурсия слишком глубокая, стек переполнен. Heap (куча) Динамическая память для объектов с неопределённым временем жизни. Выделяется при new Object(), освобождается garbage collector'ом. Memory leak = объекты не освобождаются из-за «лишних» ссылок на них. В PHP Скаляры (int, string, bool) — обычно на стеке Объекты и массивы — на куче, управляются reference counting memory_get_usage() — текущее потребление memory_limit в php.ini — максимум для одного процесса

HTTP-кеширование позволяет браузеру и прокси хранить ответы и не обращаться к серверу повторно. Управляется заголовком Cache-Control и связанными заголовками. Правильное кеширование — самая быстрая оптимизация: лучший запрос — тот, что не отправляется. Ключевые директивы Cache-Control max-age=3600 — кешировать N секунд no-cache — всегда проверять актуальность на сервере (но можно использовать кеш при 304 Not Modified) no-store — вообще не кешировать (конфиденциальные данные) public — можно кешировать прокси и CDN private — только браузер (персональные данные) immutable — содержимое никогда не изменится; браузер не проверяет до истечения max-age ETag и Last-Modified ETag — хеш содержимого. При повторном запросе браузер отправляет If-None-Match. Сервер возвращает 304 Not Modified если содержимое не изменилось — без тела ответа. Экономия трафика. Стратегия для статики Статические файлы с хешем в имени (app.abc123.js) — Cache-Control: public, max-age=31536000, immutable. Бесконечный кеш; новый деплой = новый хеш = новый URL.

HTTP-код статуса — трёхзначное число в ответе сервера, описывающее результат запроса. Первая цифра определяет класс: 2xx — успех, 3xx — перенаправление, 4xx — ошибка клиента, 5xx — ошибка сервера.Важнейшие коды200 OK — успешный запрос201 Created — ресурс создан (после POST)204 No Content — успешно, без тела ответа (DELETE)301 Moved Permanently — постоянный редирект304 Not Modified — кешированная версия актуальна400 Bad Request — неправильные данные от клиента401 Unauthorized — не аутентифицирован403 Forbidden — аутентифицирован, но нет прав404 Not Found — ресурс не существует422 Unprocessable Entity — валидация провалилась429 Too Many Requests — превышен rate limit500 Internal Server Error — ошибка сервера503 Service Unavailable — сервер временно недоступен

HTTP-методы определяют тип операции над ресурсом. REST API использует их семантически: метод выражает намерение запроса, а не только передаёт данные. Основные методы GET — получить ресурс. Идемпотентный, безопасный, кешируется POST — создать ресурс или выполнить действие. Не идемпотентный PUT — полностью заменить ресурс. Идемпотентный PATCH — частично обновить ресурс. Обычно не идемпотентный DELETE — удалить ресурс. Идемпотентный HEAD — как GET, но без тела ответа. Для проверки существования/метаданных OPTIONS — возвращает разрешённые методы. Используется в CORS preflight Safe vs Idempotent Safe — не изменяет состояние сервера (GET, HEAD, OPTIONS) Idempotent — повторный вызов даёт тот же результат (GET, PUT, DELETE) POST — ни safe, ни idempotent

HTTP/2 — вторая мажорная версия протокола HTTP, принятая в 2015 году. Решает ключевые проблемы HTTP/1.1: блокировку очереди (head-of-line blocking) и накладные расходы на открытие новых соединений.Ключевые улучшенияМультиплексирование — несколько запросов и ответов одновременно через одно TCP-соединение. Конец ограничению «6 параллельных соединений» браузераServer Push — сервер может отправить ресурс ещё до того, как клиент его запросилСжатие заголовков (HPACK) — заголовки сжимаются и не повторяются без измененийБинарный протокол — вместо текстового, эффективнее для парсингаHTTP/3Следующий шаг — HTTP/3 на базе QUIC (UDP вместо TCP). Решает head-of-line blocking на уровне транспорта. Поддерживается браузерами и CDN, но требует специфической конфигурации сервера.

HTTP/3 — третья мажорная версия HTTP, использующая QUIC (UDP) вместо TCP. Решает фундаментальную проблему HTTP/2: head-of-line blocking на транспортном уровне. Поддерживается большинством браузеров и CDN. Почему QUIC вместо TCP HTTP/2 мультиплексирует запросы в одном TCP-соединении. Но TCP гарантирует порядок: потеря одного пакета блокирует все последующие. QUIC — поверх UDP — изолирует потоки: потеря пакета блокирует только один стрим, остальные продолжают. Преимущества HTTP/3 0-RTT соединение — повторное подключение к известному серверу без дополнительного handshake Встроенный TLS 1.3 — шифрование часть протокола, а не отдельный слой Лучше на мобильных — QUIC корректно обрабатывает смену IP (роуминг) Поддержка Cloudflare, Google, Facebook, Chrome, Firefox — всё поддерживает HTTP/3. Для Nginx нужен quiche или отдельная сборка. Для большинства приложений — прозрачно через CDN.

HTTPS — HTTP поверх TLS-шифрования. Защищает данные от перехвата (man-in-the-middle) и подтверждает, что вы общаетесь именно с нужным сервером, а не с подделкой. Без HTTPS браузеры помечают сайт как «небезопасный», а SEO-рейтинг падает.Как работает TLS (упрощённо)Сервер отправляет TLS-сертификат (подписанный доверенным CA)Клиент проверяет подпись и генерирует симметричный ключ сессииВесь последующий обмен зашифрован этим ключомСертификатыLet's Encrypt — бесплатные сертификаты, автоматическое обновление через CertbotDV / OV / EV — уровни валидации: только домен, организация или расширенная проверкаHTTP Strict Transport SecurityЗаголовок Strict-Transport-Security запрещает браузеру обращаться к сайту по HTTP — даже если пользователь вручную введёт http://.