REST ou uma fila de mensagens em um sistema heterogêneo de várias camadas?

Estou projetando uma API REST para um sistema de três camadas, como: Client application-> Front-end API cloud server-> user's home API server (Home).

Homeé um dispositivo doméstico e deve manter a conexão Front-endvia Websocket ou uma pesquisa longa (este é o primeiro lugar em que estamos violando o REST. Fica ainda pior depois) . Front-endencapsula principalmente Clientsolicitações de Homeconexão e lida com algumas das chamadas em si. Às vezes Homeenvia notificações para Client.

Front-ende Hometem basicamente a mesma API; Clientpode estar se conectando Homediretamente, pela LAN. Nesse caso, Homeprecisa registrar algumas Clientações em um Front-endsi mesmo.

Os profissionais do REST neste sistema são:

• O REST é legível por humanos;
• O REST possui um mapeamento bem definido de verbos (como CRUD), substantivos e códigos de resposta para objetos de protocolo;
• Funciona sobre HTTP e passa todos os proxies possíveis;

Contras REST são:

• Precisamos não apenas de um estilo de comunicação de solicitação-resposta, mas também de publicação-assinatura;
• Os códigos de erro HTTP podem ser insuficientes para lidar com erros de comunicação em três camadas; Front-endpode retornar 202 Accepteda alguma chamada assíncrona apenas para descobrir que a Homeconexão necessária está interrompida e que deveria ter ocorrido 503;
• Homeprecisa enviar mensagens para Client. Clientterá que pesquisar Front-endou manter uma conexão.

Estamos considerando o WAMP / Autobahn over Websocket para obter a funcionalidade de publicação / assinatura, quando me ocorreu que ele já parecia uma fila de mensagens.

Vale a pena avaliar um tipo de fila de mensagens como um transporte?

Parece que os controles da fila de mensagens são:

• Vou precisar definir verbos CRUD e códigos de erro no nível da mensagem.
• Eu li algo sobre "maior custo de manutenção", mas o que isso significa?

Quão sérias são essas considerações?

Se você tiver a conectividade, vá com uma fila de mensagens - embora seja necessário definir seus próprios protocolos (dificilmente uma tarefa difícil!) Para enviar mensagens de uma estrutura e formato específicos.

O problema com a manutenção é que normalmente o cliente e o servidor são criados separadamente, portanto, você deve ter cuidado para manter as duas extremidades usando as mesmas definições de mensagens, mas se você não estiver organizado o suficiente, use o mesmo XML que você usaria no seu REST serviço.

Se você tiver problemas de conectividade pela Internet, apenas com porta 80 e http e comunicações 'unidirecionais', um sistema no estilo REST é provavelmente o melhor. Envie e faça uma sondagem ou obtenha um websocket para obter dados de retorno de chamada, mas geralmente o arquiteto do sistema deve ser cliente / servidor. Se você tem a capacidade de obter a conectividade, os sistemas de mensagens são ótimos.

Eu usaria o ZeroMQ para um sistema de mensagens, configurável o suficiente para alterar em todos os tipos de cenários, incluindo tolerantes a falhas. Não tenho certeza se funciona com http .

Parece que o Autobahn se encaixa perfeitamente no que você está tentando fazer. Existem outras ferramentas disponíveis também. Confira o Barramento de Serviço do Windows Azure (que possui estruturas de cliente para Java, .NET, PHP, Python, NodeJS e Ruby).

Enquanto as mensagens de descanso incorporadas são úteis. Você verá que seu aplicativo superará as operações básicas de CRUD. Por exemplo, se o seu aplicativo fosse um sistema bancário. Ao invés de

Atualizar conta 54321 Saldo = Saldo - 20,00 Atualizar conta 98765 Saldo = Saldo + 20,00

Você provavelmente desejaria uma única mensagem como

Transferir 20,00 da conta 54321 para a conta 98765

É melhor que você descubra esse impedimento com o REST agora ou mais tarde. Confira o Event Centric de Greg Young, que discute como criar um modelo mais rico para mensagens dentro do seu aplicativo.