WEB #

1. REST #

REST (Representational State Transfer) - это архитектурный стиль для построения WEB-API. Описывает, как клиент и сервер должны взаимодействовать через протокол HTTP

2. RESTful и RESTless #

RESTful строго следует принципам REST, используя стандартные методы HTTP и чётко структурированные URL, а RESTless нарушает эти принципы, делая взаимодействие менее стандартным и более гибким

3. REST vs SOAP #

SOAP и REST - это два разных подхода к разработке API. Подход SOAP отличается высокой степенью структурированности и использует формат данных XML. REST более гибкий и позволяет приложениям обмениваться данными в нескольких форматах

Примечание: на данный момент SOAP считается устаревшим подходом, используется только на легаси проектах

4. В каких ситуациях допустимо использование RESTless #

Использование RESTless допустимо:

• в небольшом приложение, где строгие принципы REST не критичны
• если существующая система уже использует другой подход и переделка будет слишком сложной

5. REST vs RPC. Как выбрать что лучше подходит? #

Для работы с данными обычно используют REST. Для работы с действиями, операциями (logout, login, signin) RPC будет смотреться лучше.

RPC все описывает глаголами, а REST - существительными

6. Назовите 6 принципов REST API #

• Клиент-серверная архитектура - клиент и сервер работают независимо друг от друга. Клиент отправляет запросы на сервер, сервер их принимает и возвращает ответы. Это позволяет клиенту и серверу развиваться независимо друг от друга
• Stateless (отсутствие состояния) - сервер не сохраняет информацию о состоянии клиента между запросами. Информация о текущей сессии должна целиком храниться у клиента
• Кеширование - в REST API сервер может запомнить результаты частых запросов, чтобы быстрее вернуть их результат и не тратить ресурсы на повторные вычисления
• Единообразие интерфейса - в API используются стандартные HTTP-методы, чтобы взаимодействие было простым и предсказуемым
  • GET - извлекает ресурс или коллекцию ресурсов
  • POST - создаёт новый ресурс или отправляет данные для обработки
  • PUT - полностью обновляет существующий ресурс, заменяя его новыми данными
  • PATCH - частично обновляет ресурс
  • DELETE - удаляет ресурс
• Слои - система может быть разделена на несколько слоев, каждый из которых выполняет свою задачу
• Код по требованию - иногда сервер может отправлять клиенту код (например, скрипты), который клиент может использовать для выполнения задач

Хорошая статья про принципы REST

7. Идемпотентный метод #

Идемпотентность - это свойство HTTP-запроса, при повторном исполнении давать тот же результат, что и в первый раз (без дополнительных побочных эффектов)

Пример PUT (идемпотентный)

PUT /users/1
{
    "name": "Alice",
    "email": "alice@example.com"
}

Если выполнить 100 раз, то состояние не изменится - запись просто перезапишется

Пример POST (НЕ идемпотентный)

POST /users
{
    "name": "Alice",
    "email": "alice@example.com"
}

Если выполнить 100 раз, то создастся 100 пользователей.

8. Основные HTTP методы #

• GET - получение ресурса
• POST - создание нового ресурса
• PUT - полное обновление ресурса или создание, если его нет
• PATCH - частичное обновление ресурса
• DELETE - удаление ресурса
• HEAD - получение заголовка ресурса
• OPTIONS - узнать доступные методы для ресурса

9. Статусы ответов #

• 1xx - информационные
• 2xx - успешные
• 3xx - перенаправления
• 4xx - клиентские ошибки
• 5xx - серверные ошибки

10. GET vs POST #

Почему для конфиденциальных данных рекомендуется использовать POST, а не GET запросы

1. Безопасность - в GET-запросе данные передаются в URL, который может быть виден в истории браузера, логах сервера и прокси, в POST-запросе данные передаются в теле запроса, что снижает риск случайной утечки
2. Ограничения длины - длина URL в GET ограничена браузерами или серверами, поэтому большие объемы данных (например, конфиденциальные формы) могут не пройти
3. Кэширование - GET-запросы могут быть кэшированы прокси-серверами или браузерами, что нежелательно для конфиденциальной информации

Можем ли всегда использовать только POST и не работать с GET? Теоретически - да, но это нарушает принципы REST и архитектуру веб-приложений:

1. REST-принципы - GET предназначен для получения данных, POST - для создания. Использование POST для всех операций затрудняет понимание и поддержку API
2. Оптимизация и кэширование - GET запросы могут быть кэшированы, что ускоряет работу. POST запросы не кэшируются по умолчанию
3. Поисковые системы и SEO - GET используется для индексации страниц. Если использовать только POST, страницы не попадут в поисковую выдачу

Можем ли с помощью GET создать ресурс? Есть ли технические ограничения?

1. Технические ограничения - с точки зрения HTTP-протокола GET не должен создавать ресурсы. Но технически сервер может обрабатывать GET запросы так, чтобы они изменяли данные (например, создавали ресурс)
2. Практика - создание или изменение ресурсов через GET нарушает идемпотентность и может вызвать проблемы с кэшированием и повторными запросами

Почему решили из метода GET убрать body?

1. Неопределённое поведение - семантика GET подразумевает только получение данных. Тело запроса не является обязательной частью этой семантики, поэтому серверы могут игнорировать его
2. Совместимость - многие прокси-серверы, фреймворки и библиотеки не поддерживают body в GET, что могло бы привести к проблемам совместимости.
3. Простота и идемпотентность - GET-запросы считаются идемпотентными и безопасными. Наличие тела могло бы изменить эту концепцию, создавая больше путаницы

11. Разница HTTP и HTTPs #

При использовании HTTPs данные, передаваемые серверу, зашифрованы

12. Из чего состоит HTTP запрос #

13. Какие методы авторизации существуют для HTTP протокола? #

14. Из чего состоит JSON Web Token? #

JWT (JSON Web Token) - это стандартный способ передачи информации в компактном формате (JSON) с подписью для обеспечения его целостности и подлинности. Используется для авторизации, передачи данных между клиентом и сервером

Из чего состоит JWT? JWT состоит из трех частей, разделенных точками (.):

<Header>.<Payload>.<Signature>

1. Header (заголовок) - содержит метаинформацию о токене:
   • Алгоритм подписи (например, HMAC SHA256, RSA).
   • Тип токена (JWT) Пример:

   {
     "alg": "HS256",
     "typ": "JWT"
   }
   

2. Payload (полезная нагрузка) - содержит данные (как правило о пользователе) - клеймы, которые нужно передать. Может включать:
   • зарезервированные клеймы: - стандартные поля, такие как iss (издатель), exp (время истечения), sub (субъект) и некоторые другие
   • пользовательские клеймы - любые данные, такие как роль пользователя, идентификатор и т.д. Пример:

   {
     "sub": "1234567890",
     "name": "John Doe",
     "admin": true
   }
   

3. Signature (подпись) - нужна для подписи токена, чтобы можно было проверить его подлинность. Формируется с использованием заголовка, полезной нагрузки и секретного ключа (или приватного ключа в случае асимметричного алгоритма подписи) Пример формулы:

   HMACSHA256(
     base64UrlEncode(header) + "." + base64UrlEncode(payload),
     secret
   )
   

Пример JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header - eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
2. Payload - eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
3. Signature - SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

15. Какие протоколы уровня приложений? #

Протоколы уровня приложений - это 7-й уровень модели OSI, который отвечает за взаимодействие приложений по сети

Основные протоколы:

• HTTP, HTTPS - передача данных в вебе
• FTP, SFTP - передача файлов
• SMTP, POP3, IMAP - почтовые протоколы
• WebSockets - двусторонняя связь в реальном времени
• DNS - преобразование доменов в IP
• MQTT - обмен сообщениями в IoT
• gRPC - бинарный протокол для микросервисов

Примеры использования

• Браузер (Chrome, Firefox) - HTTP/HTTPS
• Почтовый клиент (Outlook, Gmail) - IMAP/SMTP
• FTP-клиент (FileZilla) - FTP/SFTP

16. Что такое HTTP? #

HTTP (HyperText Transfer Protocol) - это протокол передачи гипертекста (текст + гиперссылки), который используется для взаимодействия браузеров и серверов

Ключевые характеристики HTTP:

• клиент-серверная модель (браузер — клиент, сервер — сайт)
• stateless (без сохранения состояния)
• текстовый протокол (легко читается)
• работает поверх TCP (обычно порт 80 для HTTP, 443 для HTTPS)

17. За что отвечают Cookie/куки? #

Cookie - это небольшой файл с данными, который браузер сохраняет от имени веб-сайта. Они передаются между клиентом и сервером через заголовки HTTP

Основные задачи Cookie

• Аутентификация - хранение сессии пользователя (JSESSIONID, session_token)
• Персонализация - запоминание настроек (язык, тема сайта)
• Трекинг и аналитика - сбор данных о пользователях (Google Analytics)
• Сохранение корзины - хранение товаров в интернет-магазине

Как работает Cookie?

1. Сервер отправляет Cookie клиенту (браузеру)

Set-Cookie: session_id=abc123; HttpOnly; Secure; Max-Age=3600

2. Клиент сохраняет Cookie и отправляет их при каждом запросе

Cookie: session_id=abc123

3. Сервер проверяет Cookie и принимает решение (например, авторизация)

Виды Cookie

Пример Set-Cookie с атрибутами

Set-Cookie: user=Alice; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Secure; HttpOnly; SameSite=Strict

18. Отличия POST, PUT, PATCH #

Дополнительные пояснения:

1. POST:

   • Используется для создания или запуска операций, которые могут изменять состояние на сервере.
   • Повторный вызов POST может приводить к дублированию ресурсов (неидемпотентность).

2. PUT:

   • Обычно подразумевает полное обновление ресурса по указанному URI.
   • Идемпотентность: повторный вызов с тем же телом запроса не изменит результат (если ресурс уже существует).

3. PATCH:

   • Позволяет частично обновлять ресурс (передаём только изменяемые поля).
   • Часто не считается идемпотентным, так как повторное применение PATCH может привести к другим изменениям, но многое зависит от реализации.

Таким образом, POST чаще всего используется для создания, PUT – для полной замены (или создания, если ресурс отсутствует), а PATCH – для частичного обновления.