WebSocket vs Server-Sent Events: Qual é Melhor para APIs em Tempo Real?

Em resumo

Use Server-Sent Events (SSE) para atualizações unidirecionais do servidor para o cliente, como notificações e feeds ao vivo. Use WebSocket para comunicação bidirecional, como chat e jogos. SSE é mais simples e funciona via HTTP. WebSocket é mais complexo, mas suporta mensagens bidirecionais. A Modern PetstoreAPI implementa ambos para diferentes casos de uso em tempo real.

Introdução

Você precisa de atualizações em tempo real em sua API. O status de um animal de estimação muda de “disponível” para “adotado” — os clientes precisam saber imediatamente. Você usa WebSocket ou Server-Sent Events (SSE)?

A maioria dos desenvolvedores opta por WebSocket porque é “mais poderoso”. Mas o SSE é frequentemente a melhor escolha. É mais simples, funciona via HTTP padrão e lida com a reconexão automaticamente. WebSocket adiciona uma complexidade que você pode não precisar.

A Modern PetstoreAPI implementa ambos os protocolos. SSE para atualizações de status de animais de estimação e notificações de pedidos. WebSocket para lances de leilão ao vivo e chat em tempo real. Cada protocolo serve a diferentes casos de uso.

💡

Se você está construindo ou testando APIs em tempo real, o Apidog suporta testes de SSE e WebSocket. Você pode testar fluxos de eventos, validar formatos de mensagem e simular cenários de reconexão.

botão

Neste guia, você aprenderá as diferenças entre SSE e WebSocket, verá exemplos reais da Modern PetstoreAPI e descobrirá quando usar cada protocolo.

O Que São Server-Sent Events (SSE)?

SSE é um protocolo baseado em HTTP para streaming de eventos do servidor para o cliente.

Como o SSE Funciona

O cliente abre uma conexão e recebe eventos à medida que acontecem:

const eventSource = new EventSource('https://petstoreapi.com/v1/pets/notifications');

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Pet update:', data);
};

eventSource.addEventListener('adoption', (event) => {
  const data = JSON.parse(event.data);
  console.log('Pet adopted:', data.petId);
});

O servidor envia eventos:

GET /v1/pets/notifications
Accept: text/event-stream

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

event: adoption
data: {"petId":"019b4132","userId":"user-456"}

event: status-change
data: {"petId":"019b4127","status":"AVAILABLE"}

Recursos do SSE

1. Comunicação unidirecional

O servidor envia para o cliente. O cliente não pode enviar mensagens de volta através da conexão SSE (mas pode usar requisições HTTP regulares).

2. Construído sobre HTTP

Usa HTTP padrão. Funciona através de proxies, firewalls e CDNs.

3. Reconexão automática

Se a conexão cair, o navegador se reconecta automaticamente.

4. IDs de Evento para retomar

O servidor pode enviar IDs de evento. O cliente retoma a partir do último evento recebido:

id: 123
event: adoption
data: {"petId":"019b4132"}

id: 124
event: status-change
data: {"petId":"019b4127"}

Se desconectado, o cliente envia o cabeçalho Last-Event-ID: 124 para retomar.

5. Protocolo simples

Formato baseado em texto. Fácil de depurar com curl:

curl -N -H "Accept: text/event-stream" \
  https://petstoreapi.com/v1/pets/notifications

Limitações do SSE

1. Apenas unidirecional

O cliente não pode enviar mensagens através do SSE. São necessárias requisições HTTP separadas para comunicação cliente-servidor.

2. Apenas texto

SSE envia texto. Dados binários devem ser codificados em base64.

3. Limites de conexão do navegador

Os navegadores limitam as conexões SSE por domínio (geralmente 6). Não é um problema para a maioria dos aplicativos.

4. Sem compressão embutida

A compressão HTTP funciona, mas não há compressão em nível de protocolo como no WebSocket.

O Que É WebSocket?

WebSocket é um protocolo bidirecional full-duplex sobre uma conexão persistente.

Como o WebSocket Funciona

Cliente e servidor podem enviar mensagens a qualquer momento:

const ws = new WebSocket('wss://petstoreapi.com/auctions/019b4132');

// Send message to server
ws.send(JSON.stringify({
  type: 'bid',
  amount: 500
}));

// Receive messages from server
ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Auction update:', data);
};

ws.onclose = () => {
  console.log('Connection closed');
  // Manual reconnection logic needed
};

O servidor pode enviar a qualquer momento:

{"type":"bid","userId":"user-456","amount":550}
{"type":"outbid","newAmount":550}

O cliente pode enviar a qualquer momento:

{"type":"bid","amount":600}
{"type":"watch","petId":"019b4132"}

Recursos do WebSocket

1. Bidirecional

Tanto o cliente quanto o servidor podem enviar mensagens a qualquer momento. Comunicação bidirecional verdadeira.

2. Baixa latência

Conexão persistente. Sem sobrecarga HTTP por mensagem. Ideal para jogos, chat, colaboração ao vivo.

3. Suporte a binários

Pode enviar dados binários diretamente. Não é necessária codificação base64.

4. Protocolo personalizado

Usa ws:// ou wss:// (seguro). Não é HTTP após o handshake inicial.

5. Baseado em frames

As mensagens são estruturadas em frames. Pode enviar mensagens parciais e remontá-las.

Limitações do WebSocket

1. Configuração complexa

Requer servidor WebSocket. Mais complexo do que endpoints HTTP.

2. Reconexão manual

Sem reconexão automática. Você deve implementar a lógica de repetição.

3. Problemas de proxy

Alguns proxies corporativos bloqueiam WebSocket. Proxies HTTP não entendem ws://.

4. Stateful (com estado)

O servidor deve rastrear as conexões. Mais difícil de escalar do que HTTP sem estado.

5. Sem recursos HTTP

Não pode usar cache HTTP, códigos de status ou cabeçalhos padrão após o handshake.

Comparação Lado a Lado

Recurso	SSE	WebSocket
Direção	Servidor → Cliente	Bidirecional
Protocolo	HTTP	Personalizado (ws://)
Reconexão	Automática	Manual
Suporte do Navegador	Todos os modernos	Todos os modernos
Compatível com Proxy	Sim	Às vezes
Complexidade	Simples	Complexo
Dados Binários	Não (apenas texto)	Sim
Latência	Baixa	Muito baixa
Escalabilidade	Alta (sem estado)	Média (com estado)
Caso de Uso	Notificações, feeds	Chat, jogos, colaboração

Como a Modern PetstoreAPI Usa Ambos

A Modern PetstoreAPI implementa tanto SSE quanto WebSocket para diferentes cenários.

SSE para Atualizações de Animais de Estimação

Endpoint: GET /v1/pets/notifications

const events = new EventSource(
  'https://petstoreapi.com/v1/pets/notifications?userId=user-456'
);

events.addEventListener('adoption', (e) => {
  const data = JSON.parse(e.data);
  showNotification(`${data.petName} was adopted!`);
});

events.addEventListener('status-change', (e) => {
  const data = JSON.parse(e.data);
  updatePetStatus(data.petId, data.status);
});

Implementação do servidor:

app.get('/v1/pets/notifications', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  const userId = req.query.userId;

  // Subscribe to pet updates
  const subscription = petUpdates.subscribe(userId, (event) => {
    res.write(`event: ${event.type}\n`);
    res.write(`data: ${JSON.stringify(event.data)}\n\n`);
  });

  req.on('close', () => {
    subscription.unsubscribe();
  });
});

Casos de uso:

Mudanças de status de animais de estimação (disponível → adotado)
Notificações de pedidos (realizado, enviado, entregue)
Atualizações de inventário
Mudanças de preço

WebSocket para Leilões ao Vivo

Endpoint: wss://petstoreapi.com/auctions/{auctionId}

const ws = new WebSocket('wss://petstoreapi.com/auctions/019b4132');

// Place bid
function placeBid(amount) {
  ws.send(JSON.stringify({
    type: 'bid',
    amount
  }));
}

// Receive updates
ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);

  switch (msg.type) {
    case 'bid':
      updateCurrentBid(msg.amount, msg.userId);
      break;
    case 'outbid':
      showOutbidNotification(msg.newAmount);
      break;
    case 'auction-end':
      showAuctionResult(msg.winner);
      break;
  }
};

Implementação do servidor:

wss.on('connection', (ws, req) => {
  const auctionId = req.params.auctionId;
  const auction = auctions.get(auctionId);

  ws.on('message', (data) => {
    const msg = JSON.parse(data);

    if (msg.type === 'bid') {
      const result = auction.placeBid(msg.userId, msg.amount);

      // Broadcast to all participants
      auction.participants.forEach(participant => {
        participant.send(JSON.stringify({
          type: 'bid',
          userId: msg.userId,
          amount: msg.amount
        }));
      });
    }
  });
});

Casos de uso:

Lances de leilão ao vivo
Chat em tempo real com suporte
Planejamento colaborativo de cuidados com animais de estimação
Atualizações de inventário ao vivo durante as vendas

Testando APIs em Tempo Real com Apidog

O Apidog suporta o teste de APIs SSE e WebSocket.

Testando SSE

1. Criar requisição SSE:

GET https://petstoreapi.com/v1/pets/notifications
Accept: text/event-stream

2. Validar eventos:

Verificar tipos de evento
Validar payloads JSON
Testar comportamento de reconexão
Verificar IDs de evento

3. Cenários de teste:

Quedas de conexão
Reinicializações do servidor
Ordem dos eventos
Retomar do último evento

Testando WebSocket

1. Criar conexão WebSocket:

wss://petstoreapi.com/auctions/019b4132

2. Enviar mensagens de teste:

{"type":"bid","amount":500}
{"type":"watch","petId":"019b4132"}

3. Validar respostas:

Verificar formatos de mensagem
Testar fluxo bidirecional
Verificar tratamento da conexão
Testar cenários de erro

4. Cenários de teste:

Múltiplas conexões concorrentes
Ordem das mensagens
Tempos limite de conexão
Lógica de reconexão

Quando Usar Cada Um

Use SSE Quando:

Atualizações unidirecionais - O servidor envia para o cliente, o cliente não precisa enviar de volta
Configuração simples - Quer usar infraestrutura HTTP padrão
Reconexão automática - Não quer implementar lógica de repetição
Compatível com Proxy - Precisa funcionar através de firewalls corporativos
Notificações - Atualizações de status, alertas, feeds ao vivo

Exemplos:

Notificações de adoção de animais de estimação
Atualizações de status de pedidos
Mudanças de inventário
Alertas de preço
Feeds de notícias

Use WebSocket Quando:

Bidirecional - Ambos, cliente e servidor, enviam mensagens frequentemente
Baixa latência crítica - Jogos, colaboração em tempo real
Dados binários - Envio de imagens, áudio, vídeo
Protocolo personalizado - Precisa de controle total sobre o formato da mensagem
Alta frequência de mensagens - Centenas de mensagens por segundo

Exemplos:

Lances de leilão ao vivo
Chat em tempo real
Jogos multiplayer
Edição colaborativa
Streaming de vídeo ao vivo

Não Use WebSocket Apenas Porque:

❌ “É mais avançado” - Complexidade sem benefício

❌ “Todos usam” - SSE é frequentemente mais simples

❌ “É mais rápido” - SSE é rápido o suficiente para a maioria dos casos de uso

❌ “É bidirecional” - Você realmente precisa de bidirecionalidade?

Conclusão

SSE e WebSocket permitem comunicação em tempo real, mas são projetados para cenários diferentes. SSE se destaca em atualizações unidirecionais do servidor para o cliente com reconexão automática e compatibilidade HTTP. WebSocket brilha em comunicação bidirecional e de baixa latência.

A Modern PetstoreAPI mostra como usar ambos os protocolos de forma eficaz. SSE para notificações e atualizações de status. WebSocket para leilões ao vivo e chat. Escolha com base no seu caso de uso, não em qual protocolo parece “melhor”.

Teste suas APIs em tempo real com Apidog para garantir que ambas as implementações de SSE e WebSocket funcionem corretamente em diferentes cenários.

Perguntas Frequentes

O SSE pode funcionar através de firewalls corporativos?

Sim. O SSE usa HTTP padrão, então funciona através de proxies HTTP e firewalls. O WebSocket usa um protocolo personalizado que alguns proxies bloqueiam.

O WebSocket é mais rápido que o SSE?

O WebSocket tem uma latência ligeiramente menor (sem sobrecarga HTTP por mensagem), mas para a maioria das aplicações, a diferença é insignificante. O SSE é rápido o suficiente para notificações, feeds e atualizações de status.

Como você lida com a reconexão do SSE?

O navegador lida com a reconexão automaticamente. Envie IDs de evento do servidor, e o cliente retomará do último evento recebido usando o cabeçalho Last-Event-ID.

Você pode usar SSE com aplicativos móveis?

Sim. iOS e Android suportam SSE através de clientes HTTP nativos ou bibliotecas. O SSE funciona onde quer que o HTTP funcione.

Qual é o tempo máximo de conexão SSE?

Não há limite rígido. As conexões SSE podem permanecer abertas indefinidamente. Alguns proxies ou balanceadores de carga podem ter tempos limite (geralmente 30-60 segundos), mas o navegador se reconectará automaticamente.

O WebSocket pode enviar dados binários?

Sim. O WebSocket suporta frames de texto e binários. Você pode enviar imagens, áudio ou quaisquer dados binários sem codificação base64.

Quantas conexões SSE um navegador pode ter?

Os navegadores limitam as conexões SSE por domínio (geralmente 6). Isso raramente é um problema – a maioria dos aplicativos precisa de apenas 1-2 conexões SSE.

Você precisa de um servidor especial para SSE?

Não. Qualquer servidor HTTP pode lidar com SSE. Basta definir os cabeçalhos corretos (Content-Type: text/event-stream) e manter a conexão aberta.