A tecnologia WebSockets têm crescido em popularidade e disponibilidade nos últimos anos, e no final do último ano ficou mais perto de se transformar em um padrão, por ter se tornado um W3C Candidate Recommendation. A Oracle e outras organizações submeteram recentemente um pedido para iniciar um esforço de padronização em torno do WebSockets (JSR 356) na próxima versão do Java EE. Todos os maiores navegadores, como Chrome, Firefox, Safari e IE, suportam uma das revisões do WebSockets e irão futuramente adotar o padrão que for definido. Num período de tempo relativamente curto, o WebSockets quase se tornou uma parte integral da web. Mas parte dos desenvolvedores ainda estão incertos sobre como ou se o WebSockets se encaixa na arquitetura da web "tradicional": o REST. Alguns, como Nathan Evans, chegam ao ponto de sugerir que os WebSockets podem ofuscar o REST de vez:
Depois de ler o padrão em detalhes e analisar discussões online sobre ele, tornou-se claro para mim que o WebSockets irá tomar uma grande parcela do interesse em web services do tipo RESTful. Haverá um ponto no desenvolvimento de produtos em que alguém terá de fazer a pergunta, "Devemos usar WebSockets ou REST neste projeto?" Minha expectativa é que o WebSockets irá, dentro de um ano ou dois, começar a tolher o crescimento dos web services REST, ao menos como os conhecemos hoje.
Em seu artigo, Nathan Evans acredita que, baseado em suas experiências usando a tecnologia, o REST não é a "bala de prata" que alguns descrevem, embora admita que o WebSockets também não é perfeito. Ele cita algumas razões porque o WebSockets seria uma ameaça ao REST, incluindo as dependências que têm certos frameworks "de baixa qualidade" em relação a protocolos baseados em texto. Algum dos benefícios importantes que o WebSockets oferece em relação ao REST incluem, entre outros, interações bidirecionais.
A capacidade bidirecional verdadeira oferecida pelo WebSockets é pioneira em protocolos baseados no HTTP. É algo que nem SOAP nem REST têm e que Comet ou push/long-polling, podem somente emular, e isso de forma ineficiente. A capacidade bidirecional é tão boa que se pode tunelar um protocolo TCP de tempo real, como Remote Desktop ou VNC, sobre um WebSocket.
Nathan Evans acredita que os benefícios do WebSockets superam os do REST/HTTP e que os desenvolvedores irão migrar em direção ao WebSockets.
O REST irá provavelmente continuar a ser a escolha padrão para projetos que precisam de alta visibilidade e de web services interoperáveis independente da plataforma. Projetos sem esses requisitos irão provavelmente optar por WebSockets, e executar JSON sobre a tecnologia, ou usar um protocolo de rede personalizado. Mesmo havendo uma competição entre as duas tecnologias, o interessante é que tanto o REST quanto o WebSockets podem coexistir. Devido ao fato de ambos serem construídos sobre fundamentos do HTTP, irão complementar-se um ao outro.
Evans não é o único a levantar a questão de WebSockets contra REST. Shay Bannon, por exemplo, questionou em 2010 se é mesmo possível usar os princípios do REST com o WebSockets:
Como se representa uma URI? Como são representados os métodos HTTP (GET, PUT, POST etc.)? Como se representam os parâmetros de URIs e seus cabeçalhos? Uma solução para isso seria criar algum tipo de esquema (schema) no conteúdo, que vá inserido num string de texto; alguma coisa como um texto no formato JSON que contenha um campo "uri", "params" e assim por diante. Mas isso é trabalhoso, pois com HTTP pode-se criar gateways muito simples que meramente usem os cabeçalhos ou parâmetros, sem a necessidade de analisar o conteúdo do corpo.
Bannon se pergunta porque o WebSockets não prevêem o conceito de URI ou de cabeçalho, e se haveria a necessidade de criar uma especificação REST sobre WebSockets, antes que as pessoas reinventem o REST e terminem fazendo isso "de uma maneira não uniforme". Por exemplo, em um comentário ao texto de Bannon (vindo de uma empresa que usa WebSockets), foi dito:
Comunicações usando REST e WebSockets parecem ser dois tipos diferentes de "encanamento" para computação distribuída. O REST é a escolha tradicional, construída sobre o HTTP, com um estilo síncrono de RPC (chamada remota de procedimentos) pela web. O WebSockets é a opção mais nova, com base em algo paralelo ao HTTP, normalmente com estilo de comunicação web assíncrono. Na minha opinião, no longo prazo o WebSockets irá dramaticamente reduzir a necessidade do REST na computação WAN (redes de longa distância). Com WebSockets, todos os protocolos que conhecemos e amamos nas últimas décadas podem agora ser estendidas por sobre a web, sem usar um mapeamento forçado e ineficiente do HTTP.
E outra:
Minha opinião é que o REST envolve o paradigma convencional de requisição/resposta. De maneira oposta, o WebSockets atende ao cenário Comet/long polling, em que a linha de comunicação permanece aberta por vários ciclos de comunicação. Também, o handshakeinicial com o WebSockets ainda ocorre a partir do HTTP; assim, na realidade, as tecnologias não são mutuamente exclusivas. Também acho que a ideia do protocolo do WebSockets era se livrar da sujeira dos cabeçalhos HTTP, por se tornarem redundantes e somente adicionar peso ao tráfego de dados.
Embora concordem que o REST e o WebSockets possam e devam coexistir, muitos comentaristas discordam quanto ao conceito de uma especificação "REST-sobre-WebSockets". Um deles adiciona:
Se você considerar o REST no mesmo sentido utilizado por Fielding, com uma rede de objetos endereçáveis (ou recursos), isso não funciona em um formato de comunicação duplex. Não se espera que os recursos iniciem a conversação. Os WebSockets irão transformar a web (se decolarem), mas não como um protocolo para comunicações no estilo do REST.
Outro comentarista oferece um ponto de vista mais detalhado:
Os WebSockets são full duplex, ou seja, ambos os lados podem falar ao mesmo tempo, e ambos os lados têm de manter suas capacidades de escuta ligadas enquanto estão falando. O REST é um tipo de arquitetura sem estado e síncrona, que lida somente com requisições e respostas. Teria que ser expandido o conceito de REST para se obter o benefício de uma comunicação servidor/cliente sem solicitação anterior. Imagino os benefícios de uma biblioteca que implemente REST em WebSockets, mas ela só seria útil para aplicações que já têm uma API RESTful e que buscam obter o benefício de uma exigência menor de recursos sem refatorar o código.
Também há alguns na comunidade REST, tais como Jim Webber, que acreditam que os WebSockets não são adequados para a web.
Com o WebSockets perto de se tornar um padrão, e sendo suportado e utilizado em navegadores, dispositivos móveis e na nuvem, é interessante considerar qual o impacto a tecnologia terá sobre os desenvolvedores que atualmente usam REST e HTTP. Com o WebSockets estaríamos correndo o risco de "quebrar a web"?