HTTP RESTful e websocket no mesmo aplicativo?

Se um aplicativo já tiver sido aberto WebSocketpara feeds ao vivo, devo usá-lo AJAXpara outras comunicações com o servidor?

Como a conexão já está aberta, devemos usá-la para solicitações que Request/Responsenão são em tempo real?

Prefiro RESTful HTTPsolicitações porque as acho mais fáceis de depurar. Você pode usar um navegador com URLs ou cachos para testar o que a API retorna. Você não precisa escrever um código para abrir a WebSocket.

Seria estranho ter RESTful HTTP APIum WebSocketna mesma aplicação?

rest ajax websockets

— Marc
fonte

"você não precisa escrever nenhum código para testar a API" Você poderia explicar isso um pouco mais? O que faz você pensar que não precisa testar a API?

— Elias Van Ootegem

Ferramentas para Desenvolvedores Chrome, se não me engano permitem que você abra um websocket e enviar mensagens em tempo real

— maple_shaft

@EliasVanOotegem Good point. Desculpe isso não estava claro. Você ainda precisa testar a API com um projeto de unidade no lado do servidor. O que quero dizer é que, se você quiser uma rápida olhada no que a API retornaria, poderá usar um broswer com o URL. Você não precisa escrever um código para abrir um soquete da web. Eu atualizei minha pergunta.

— Marc

@ maple_shaft Isso é bom, mas você precisa estar em uma página com um WebSocket aberto para o servidor.

— Marc

Um dos principais objetivos de design do Websockets é permitir que os protocolos HTTP e Websocket sejam comunicados na mesma porta. Isso é possível exigindo explicitamente que um cliente execute um handshake Websocket com uma solicitação de Atualização HTTP. Dessa maneira, o servidor pode manipular uma conexão de solicitação HTTP padrão, bem como uma solicitação de Atualização HTTP que agora é atualizada para uma conexão duplex bidirecional persistente.

Então, sim, este é definitivamente um caso de uso válido, no entanto, se você DEVE fazer isso para a sua aplicação específica, é um assunto totalmente diferente. Os Websockets são úteis e fazem sentido nos cenários em que o servidor deve ter a capacidade de enviar dados não solicitados ao cliente (feeds ativos). O protocolo HTTP e os serviços REST são úteis onde você deseja bloquear a solicitação síncrona de dados do cliente.

Se seus requisitos são tais que ambos fazem sentido para o seu aplicativo, você deve usar os dois. Se, no entanto, sua única interação com o servidor for baseada em feed ao vivo, os serviços REST não serão adequados. Acho que a facilidade de depuração deve ter uma importância bastante baixa em termos de Atributos de Qualidade do Sistema nos quais você deve arquitetar seu design.

— maple_shaft
fonte

Era isso que eu estava pensando. Faz sentido usar websockets para feed ao vivo em tempo real, mas e as operações CRUD? Faz mais sentido em minha mente usar uma solicitação HTTP padrão para eles.

— Marc

@ Marc, eu não acharia estranho separar operações CRUD e preocupações em tempo real (uma usando HTTP e outras Websockets) ... mas ... acredito que você obterá melhor capacidade de resposta do servidor, bem como melhor desempenho, se você utilizar a conexão persistente (Websocket) para todas as suas operações. Isso realmente depende de quais são suas necessidades de CRUD, mas eu não evitaria uma interface CRUD Websocket.

— Myst

votado! novato aqui, como você mencionou que ambos devem ser comunicados pela mesma porta, se você está buscando, digamos, preços das ações de uma transmissão ao vivo e, devido ao tráfego intenso, o fluxo se desconecta por alguns minutos, como você obteria os dados entre ou o que existem estratégias para lidar com esse caso

— PirateApp