Web #

1. REST #

REST - это архитектурный стиль взаимодействия клиент-серверного WEB-приложения. Клиент-сервер общаются через протокол HTTP (HTTPs), а формат данных - JSON (XML).

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 используются стандартные команды (GET, POST, PUT, DELETE), чтобы взаимодействие было простым и предсказуемым
• Многоуровневость системы: Система может быть разделена на несколько слоев, каждый из которых выполняет свою задачу
• Код по требованию: Иногда сервер может отправлять клиенту код (например, скрипты), который клиент может использовать для выполнения задач

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

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

✅ Идемпотентные 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. Статусы ответов #

• 100-199. Информационные
• 200-299. Успешные
• 300-399. Перенаправления
• 400-499. Клиентские ошибки
• 500-599. Серверные ошибки

10. GET vs POST #

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

1. Безопасность:

• В GET запросе данные передаются в URL, который может быть виден в истории браузера, логах сервера и прокси.
• В POST данные передаются в теле запроса, что снижает риск случайной утечки.

2. Ограничения длины:

• Длина URL в GET ограничена браузерами или серверами, поэтому большие объемы данных (например, конфиденциальные формы) могут не пройти. При использовании метода GET можно использовать не более 2048 символов за вычетом количества символов в фактическом пути.

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 нарушает идемпотентность и может вызвать проблемы с кэшированием и повторными запросами.

3. Рекомендация:

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

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

1. Неопределённое поведение:

   • Семантика GET подразумевает только получение данных. Тело запроса не является обязательной частью этой семантики, поэтому серверы могут игнорировать его.

2. Совместимость:

   • Многие прокси-серверы, фреймворки и библиотеки не поддерживают body в GET, что могло бы привести к проблемам совместимости.

3. Простота и идемпотентность:

   • GET запросы считаются идемпотентными и безопасными. Наличие тела могло бы изменить эту концепцию, создавая больше путаницы.

4. Архитектурное решение:

   • Для сложных запросов с данными в теле рекомендуется использовать POST, а для простых запросов — GET. Это упрощает архитектуру и делает API предсказуемым.

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

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

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

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

JWT — это стандартный способ передачи информации в компактном формате (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 (для кодирования/декодирования можно использовать ресурс jwt.io):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

1. Header (Base64 URL):

   eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
   

2. Payload (Base64 URL):

   eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0
   

3. Signature:

   KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30
   

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?

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

1. Сервер проверяет 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 – для частичного обновления.