Relazione tra URI RESTful e argomenti PubSub

5

Sto progettando un sistema che si adatta abbastanza bene a un'architettura RESTful. Gli utenti possono navigare una gerarchia di risorse da un nodo radice, ogni risorsa collega ad altre risorse, le risorse hanno URI ecc. In molti modi questo è molto simile al 99% delle applicazioni web CRUD là fuori.

Dove le cose diventano un po 'diverse è che voglio integrare un modello Pub / Sub in questa architettura. Quindi, quando una risorsa viene modificata, voglio che l'architettura supporti gli aggiornamenti che vengono espulsi dai relativi abbonati.

Molte delle mie domande riguardano il modo in cui gli "argomenti" Pub / Sub si riferiscono agli "URI" RESTful. In realtà voglio solo usare l'URI come argomento. Mi sento come in molti scenari che ha perfettamente senso - ma ho un problema di dubbio su questo e non riesco a trovare alcuna architettura in natura facendo questo.

Dove diventa strano è che alcuni URI sono query che non si adattano facilmente a questo modello. È troppo complesso per supportare le query pub / sub dynamic e non ho alcuna intenzione o necessità, ma il fatto che questo concetto sia ampiamente implementato nei sistemi RESTful ci fa pensare che ci sia una discrepanza o una limitazione nell'uso degli URI come argomenti in pub / sub sistema.

La mia risoluzione al momento è che gli URI "canonici" (cioè quelli che si riferiscono a una singola risorsa in una posizione canonica) vanno bene, o anche una buona cosa, da usare come argomento. Ma la mia fiducia è bassa perché non vedo gli altri farlo.

Ogni pensiero è stato apprezzato.

    
posta Schneider 15.09.2016 - 05:01
fonte

2 risposte

7

Mappare gli URI (dalle risorse REST) agli argomenti, a seconda di cosa stai modellando, potrebbe portare a una mappatura perfetta.

Attraverso un semplice esempio, cercherò di darti qualche suggerimento su come eseguire questa mappatura. Prenderò come esempio due APIS: un'API REST (risorse) e un'API MQTT (argomenti).

A proposito, MQTT è un protocollo pub / sub per l'Internet of Things e M2M: ci sono alcuni argomenti che si trovano in un broker MQTT dove i clienti possono pubblicare ( PUB topic1/topic2/... ) o iscriversi ( SUB topic1/topic2/... ).

Suggerimento 1: una rappresentazione delle risorse è un messaggio

L'idea è di mappare l'URI della risorsa con il nome di un argomento corrispondente. Quindi la rappresentazione della risorsa da un URI di risorsa corrisponde a un messaggio in un argomento.

Immagina di avere un nome di risorsa /people/:id , avrai un nome argomento corrispondente /people/:id .

Quindi, quando un cliente crea un PUT /people/1 { "loveBeer":true } , i clienti che hanno sottoscritto questo argomento (attraverso un SUB /people/1 ) riceveranno una notifica. Si noti che anche PATCH potrebbe essere utilizzato. Lo stesso si applica al contrario, se un cliente pubblica un messaggio nell'argomento PUB /people/1 "loveBeer":true , la risorsa corrispondente sarà aggiornata.

Si finirebbe con questo tipo di architettura (l'immagine è presa da questo blog ):

Suggerimento2:lecreazionidellerisorsesonoanchemessaggi

Dall'esempioprecedente,potrestipensare...

Hey,whataboutclientcreatinganewresourcethroughPOST/people?

Creeraiunanuovarisorsaeunmessaggiosaràpubblicatonell'argomentocorrispondente(/people)

Adesempio,seunclienteseguePOST/people{"name":"schneider", loveBeer:true} . I clienti che hanno eseguito SUB /people riceveranno la notifica

Quindi potresti ripensarci e dire:

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

Immagina che un client crei PUB /people {"name":"Ailurus", "loveBeer":true} , quando il messaggio è ricevuto, viene creata una nuova risorsa /people/42 e i client sono iscritti a /people .

Suggerimento bonus: considera i metadati

Questo non è proprio un suggerimento, dal momento che non è realmente correlato a una mappatura tra l'URI / argomento della risorsa:)

Da questo blog , i metadati potrebbero essere aggiunti nel carico utile dei messaggi pubblicati (ma non nella rappresentazione della risorsa).

Principalmente perché il client MQTT che sottoscrive un argomento non sa se una risorsa viene aggiornata o creata, mentre un client REST conosce questa informazione (quando viene creata una risorsa, tramite l'intestazione della posizione) Quindi considera di aggiungere metadati come "event": "created" o '"evento": "modificato"

Potresti anche pensare a quando viene creata una risorsa, oltre a mettere {"event": "created"} nel payload, per dare l'URI della risorsa / nome dell'argomento, come {"event": "created", "location": "people/42"}

    
risposta data 16.09.2016 - 15:40
fonte
1

Un abbonamento a un argomento può essere eseguito con un POST su un URI di argomento. Ciò dovrebbe generare una coda che viene restituita nella risposta per il sottoscrittore inviduale.

Usando POST su questa coda URI dovrebbe creare un nuovo URI che contiene un feed di elementi (URIs ai messaggi) che devono essere consegnati all'utente. Dopo aver ottenuto GET in questo stato di avanzamento corrente, è possibile ottenere elementi selezionati a cui si riferisce il feed. Se gli elementi sono condivisi (probabilmente è ciò che la maggior parte delle persone desidera), non è possibile eliminarli. Hai bisogno di POST di nuovo per contrassegnarli consegnati.

Un nuovo POST sull'URI della coda creerà nuovamente un feed con gli elementi in coda correnti (probabilmente quelli che non sono stati contrassegnati come consegnati). Ma questa è la tua scelta su come vuoi gestire i messaggi.

Ovviamente la sottoscrizione può essere DELETEd quando si desidera annullare l'iscrizione ed è consigliabile che alcuni URI (feed ed eventualmente articoli) abbiano restrizioni di scadenza per mantenere il sistema pulito.

    
risposta data 15.09.2016 - 12:03
fonte

Leggi altre domande sui tag