Relação entre URIs RESTful e tópicos PubSub

5

Eu estou projetando um sistema que se encaixa muito bem em uma arquitetura RESTful. Os usuários podem navegar em uma hierarquia de recursos a partir de um nó raiz, cada recurso é vinculado a outros recursos, os recursos possuem URIs etc. De muitas maneiras, isso é muito semelhante a 99% dos aplicativos da Web CRUD existentes.

Quando as coisas ficam um pouco diferentes, quero integrar um modelo Pub / Sub a essa arquitetura. Assim, quando um recurso é modificado, quero que a arquitetura ofereça suporte às atualizações que estão sendo enviadas pelos inscritos relevantes.

Muitas das minhas perguntas estão relacionadas a como os 'tópicos' do Pub / Sub se relacionam com 'URIs' RESTful. Realmente, quero apenas usar o URI como o tópico. Eu sinto que em muitos cenários isso faz todo o sentido - mas eu tenho uma pequena dúvida sobre isso e não consigo encontrar nenhuma arquitetura na natureza fazendo isso.

Onde fica estranho é que algumas URIs são consultas que não se encaixam facilmente neste modelo. É muito complexo para suportar consultas dinâmicas de pub / sub e não tenho intenção ou necessidade, mas o fato deste conceito ser amplamente implementado em sistemas RESTful faz com que pareça que há uma incompatibilidade ou limitação no uso de URIs como tópicos em pub / sub sistema.

Minha resolução no momento é que URIs 'canônicos' (ou seja, aqueles que se referem a um único recurso em um local canônico) são bons, ou até mesmo bons, para usar como tópico. Mas minha confiança é baixa devido a não ver outras pessoas fazendo isso.

Quaisquer pensamentos apreciados.

    
por Schneider 15.09.2016 / 05:01
fonte

2 respostas

7

Mapeamento de URIs (de recursos REST) para tópicos, dependendo do que você está modelando, pode resultar em um mapeamento perfeito.

Por meio de um exemplo simples, tentarei fornecer algumas dicas sobre como realizar esse mapeamento. Eu tomaria como exemplo, dois APIS: uma API REST (recursos) e API MQTT (tópicos).

A propósito, MQTT é um protocolo de publicação / assinatura para a Internet of Things e M2M: há alguns tópicos localizados em um broker MQTT onde os clientes podem publicar ( PUB topic1/topic2/... ) ou se inscrever ( SUB topic1/topic2/... ).

Dica 1: uma representação de recurso é uma mensagem

A ideia é mapear seu URI de recurso com um nome de tópico correspondente. Assim, a representação de recursos de um URI de recurso corresponde a uma mensagem em um tópico.

Imagine que você tem um nome de recurso /people/:id , você terá um nome de tópico correspondente /people/:id .

Portanto, quando um cliente fizer um PUT /people/1 { "loveBeer":true } , os clientes que se inscreverem neste tópico (por meio de SUB /people/1 ) receberão uma notificação. Observe que PATCH pode ser usado também. O mesmo se aplica ao contrário, se um cliente publicar uma mensagem no tópico PUB /people/1 "loveBeer":true , o recurso correspondente será atualizado.

Você acabaria com esse tipo de arquitetura (a foto é tirada de blog ):

Dica2:criaçõesderecursostambémsãomensagens

Doexemploanterior,vocêpoderiapensar...

Hey,whataboutclientcreatinganewresourcethroughPOST/people?

Vocêcriaráumnovorecursoeumamensagemserápublicadanotópicocorrespondente(/people)

Porexemplo,seumclienteexecutarPOST/people{"name":"schneider", loveBeer:true} . Clientes que realizaram SUB /people receberão a notificação

Então você pode pensar de novo e dizer:

Hey, what about client publishing a message in a topic through PUB /people ? Vice-versa, it will create a message in the topic /people and create a new sub-resource /people/:newid

Imagine um cliente fazendo PUB /people {"name":"Ailurus", "loveBeer":true} , quando a mensagem é recebida, um novo recurso /people/42 é criado e os clientes se inscreveram para /people são notificados.

Dica de bônus: considere metadados

Isso não é realmente uma dica, já que não está realmente relacionado a um mapeamento entre URI / tópico de recurso:

Deste blog , meta-dados podem ser adicionados na carga útil das mensagens publicadas (mas não na representação de recursos).

Principalmente porque o Cliente MQTT que se inscreve em um tópico não sabe se um recurso é atualizado ou criado, enquanto um cliente REST conhece essas informações (quando um recurso é criado, através do cabeçalho de localização) Portanto, considere incluir metadados como "event": "created" ou '"event": "modified"

Você pode até pensar em quando um recurso é criado, além de colocar {"event": "created"} na carga, para fornecer o nome do URI / tópico do recurso, como {"event": "created", "location": "people/42"}

    
por 16.09.2016 / 15:40
fonte
1

Uma assinatura de um tópico pode ser feita com um POST para um URI de tópico. Isso deve gerar uma fila retornada na resposta para o assinante invididual.

Usando o POST nesta fila, o URI deve criar um novo URI que contenha um feed de itens (URIs para as mensagens) que precisam ser entregues ao usuário. Depois de GET neste estado de feed atual, você pode obter os itens selecionados a que o feed se refere. Se os itens forem compartilhados (provavelmente é o que a maioria das pessoas deseja), não é possível excluí-los. Você precisa de POST novamente para marcá-los.

Um novo POST no URI da fila criará novamente um feed com itens enfileirados atuais (possivelmente os que também não foram marcados como entregues). Mas esta é a sua escolha como você quer lidar com as mensagens.

É claro que a assinatura pode ser DELETADA quando você deseja cancelar a assinatura e é aconselhável que alguns URIs (feeds e eventualmente itens) tenham restrições de expiração para manter o sistema limpo.

    
por 15.09.2016 / 12:03
fonte