Какие основные протоколы и технологии используются для обмена данными между клиентом и сервером в веб-приложениях?

Ответ

Выбор технологии зависит от требований к данным: частота обновления, объём, необходимость двусторонней связи.

Технология Протокол Модель Основное назначение
HTTP/1.1, HTTP/2, HTTP/3 TCP/QUIC Запрос-ответ Классические RESTful API, загрузка статики, формы.
WebSocket WS/WSS (поверх TCP) Дуплексная, постоянное соединение Real-time: чаты, биржевые тикеры, онлайн-игры.
Server-Sent Events (SSE) HTTP Односторонняя (сервер → клиент) Уведомления, ленты новостей, мониторинг статуса.
GraphQL HTTP (обычно POST) Запрос-ответ (гибкий запрос) Запрос специфичных данных, избегание over/under-fetching.
gRPC HTTP/2 Запрос-ответ (бинарный) Высокопроизводительная межсервисная коммуникация (микросервисы).

Примеры и ключевые аспекты для тестирования:

  1. REST API (HTTP):

    // Тестирование: статус-коды, заголовки, тело ответа, время отклика.
    fetch('https://api.example.com/users/1', {
        method: 'PUT',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ name: 'New Name' })
    })
    .then(response => {
        if (!response.ok) throw new Error(`HTTP ${response.status}`);
        return response.json();
    });

    Тестируем: Валидацию JSON-схемы, кэширование, idempotency методов, безопасность (CORS, токены).

  2. WebSocket:

    const ws = new WebSocket('wss://echo.websocket.org');
    ws.onopen = () => ws.send('Hello Server!');
    ws.onmessage = (event) => console.log('Received:', event.data);
    ws.onerror = (error) => console.error('WebSocket Error:', error);

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

  3. GraphQL:

    # Запрос: клиент точно определяет, какие поля нужны.
    query GetUserWithPosts($userId: ID!) {
      user(id: $userId) {
        name
        email
        posts(limit: 5) {
          title
          createdAt
        }
      }
    }

    Тестируем: Корректность резолверов, обработку ошибок, защиту от сложных/глубоких запросов (max depth, query cost analysis), интроспекцию.

  4. SSE:

    const eventSource = new EventSource('/api/stream');
    eventSource.onmessage = (e) => updateDashboard(JSON.parse(e.data));

    Тестируем: Формат событий (data:, event:, id:), повторное подключение при потере связи, кодировку.

Для тестировщика критично понимать различия, чтобы правильно планировать проверки сетевого взаимодействия, безопасности и производительности.

Ответ 18+ 🔞

Слушай, а вот этот твой выбор технологии — это ж как в магазине: подходишь к прилавку, а там тебе и селёдка под шубой, и красная икра, и доширак. И ты стоишь, такой: «Ну что взять-то, блядь?». А ответ-то простой — смотри, нахуй, что тебе надо.

Вот смотри таблицу, она вроде как умная, но я её на пальцах объясню, а то ты щас глаза сломаешь.

HTTP — это как старый добрый почтальон Печкин. Принёс тебе письмо (запрос), ты ему ответ написал (ответ), и он пошёл нахуй до следующего раза. Тестировать его — это проверять, не перепутал ли он адрес (статус-коды), не порвал ли конверт (заголовки), и не несёт ли он вместо письма кирпич (валидация тела). И, главное, не тырит ли он твои посылки (безопасность, CORS). Код вот этот твой fetch — это и есть Печкин в работе. Сделал PUT — проверил, что ответ ok. Не ok? Ну всё, пошёл нахуй с ошибкой.

// Тестирование: статус-коды, заголовки, тело ответа, время отклика.
fetch('https://api.example.com/users/1', {
    method: 'PUT',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ name: 'New Name' })
})
.then(response => {
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    return response.json();
});

WebSocket — это уже не почтальон, а твой сосед-болтун, который вломился к тебе в дом, сел на диван и несёт хуйню без остановки в обе стороны. Соединение установил — и понеслась. Тут тестировать надо, а что если он, сука, вдруг отключится (разрыв соединения)? Вернётся ли, наглый, обратно (реконнект)? А если он начнёт тебе не текст, а картинки голые слать (бинарные данные) — твой клиент не обосрётся? А если таких болтунов-соседей будет овердохуища — сервер выдержит?

const ws = new WebSocket('wss://echo.websocket.org');
ws.onopen = () => ws.send('Hello Server!');
ws.onmessage = (event) => console.log('Received:', event.data);
ws.onerror = (error) => console.error('WebSocket Error:', error);

SSE (Server-Sent Events) — а это уже не болтун, а начальник, который стоит у тебя над душой и орет указания, а ты, блядь, только ушами хлопать можешь. Сервер тебе стримит, а ты молчишь в тряпочку. Тестируй тут: а правильно ли он орёт (формат событий data:, event:)? А если он запнётся и замолчит (потеря связи) — ты поймёшь, что он сдох, и попробуешь его снова найти? И вообще, тот бред, который он несёт, — он читаемый (кодировка)?

const eventSource = new EventSource('/api/stream');
eventSource.onmessage = (e) => updateDashboard(JSON.parse(e.data));

GraphQL — это, блядь, хитрая жопа. Ты приходишь в шаурмичную и начинаешь: «Дайте мне лаваш, но без помидора, с двойным мясом, огурцов положите, но только с левого лотка, и полейте чесночным, но смешайте его с кетчупом...». То есть ты сам выёбываешься и составляешь идеальный запрос. Тестировать тут — это смотреть: а повар (резолвер) не обосрётся от такого заказа и правильно ли всё соберёт? А если ты попросишь не шаурму, а весь его холодильник разобрать (сложный/глубокий запрос) — он тебе по ебалу не даст? (защита от max depth). И вообще, а есть ли у него меню вообще? (интроспекция).

# Запрос: клиент точно определяет, какие поля нужны.
query GetUserWithPosts($userId: ID!) {
  user(id: $userId) {
    name
    email
    posts(limit: 5) {
      title
      createdAt
    }
  }
}

gRPC — это уже для своих, для взрослых дяденек в микросервисах. Они там между собой на бинарном языке общаются, быстро-быстро, как из пулемёта. Тестировать это — отдельная песня, но суть та же: летит ли сообщение, понимают ли они друг друга, и не обманывает ли один другого.

Короче, ёпта, мораль простая. Прежде чем тестировать — врубись, кто перед тобой: почтальон, болтун, начальник, привередливый клиент или секретный агент. И тыщи ему, блядь, соответствующих вопросов. А то будешь у WebSocket статус-коды спрашивать — он тебе в ответ молчанием, сука, таким охуеешь.