Astratto

Sto lavorando su un'interfaccia REST a un database grafico (Titan / Gremlin-Server, ma questo non dovrebbe importare) che ha un strong senso del tipo per vertici e spigoli. Mi piacerebbe progettare un'API REST per eseguire operazioni CRUD mentre impongo alcune informazioni sul tipo.

Panoramica

Lo scopo di questo database è di modellare il flusso di informazioni (un'unità di cui è chiamato un messaggio ) tra vari attori , tenendo traccia di canali che mediano il routing dei messaggi. Ad esempio, si può dire che un YouTuber (tipo: attore) produce un video (tipo: messaggio) e lo distribuisce tramite un canale YouTube (tipo: canale), a cui è iscritto un altro YouTuber (tipo: attore).

Il modello dati è il seguente con i vertici rappresentati come caselle e spigoli rappresentati come frecce:

                              publish
|***************| ---------------------------------> |*******************|
|               |                                    |                   |
|               |  produce   |*********|  distribute |                   |
|    Actor      | ---------> |         | ----------> |      Channel      |
|               |            | Message |             |                   |
|               | <--------- |         | <---------- |                   |
|               |  notify    |*********|   deliver   |                   |
|               |                                    |                   |
|***************| <--------------------------------- |*******************|
                              subscribe

Per aiutare a capire, si dice che:

• Un attore pubblica su un canale
• Un attore produce un messaggio
• Un messaggio notifica un attore (inversamente dichiarato: un attore riceve notifica di un messaggio)
• Un messaggio viene distribuito tramite un canale
• Un canale recapita un messaggio (inversamente dichiarato: un messaggio è fornito da un canale)
• Un canale sottoscrive un attore (inversamente dichiarato: un attore è iscritto a un canale)

Si noti come i tipi dei vertici in ogni operazione di creazione di un bordo, createE(v1, v2) , determina il tipo di bordo che viene creato. Ad esempio, un margine da Actor a Message è necessariamente un margine produce . Allo stesso modo, un margine da Channel a Actor è necessariamente un margine subscribe .

N.B.: Vertices in this model constitute (I think...) a mathematical category. We can think of edges as functions that map one category to another. For example, the function that takes us from an Actor to a Channel is called publish, and is equivalent to distribute ∘ produce. I mention this because I had these principles in mind when designing the data model ... perhaps they can be leveraged for a REST API?

Dichiarazione del problema

Dato il modello di dati sopra, ho bisogno di creare un'API REST che supporti le operazioni CRUD di base sia per i vertici che per i bordi. Come minimo, l'API dovrebbe:

1. Operare su entrambe le singole risorse e raccolte
2. Fornire un meccanismo per vincolare i vertici / i bordi su cui opera una determinata chiamata API (un esempio informale e non esaustivo: "Voglio creare uno spigolo che va dal vertice con UUID 5F1506A2-4824-416D-95F2-BC2D82B15A29 a tutti i vertici creati nel ultima ora)
3. Inferere il tipo di bordo da creare in base ai tipi di vertice di origine e di destinazione, con l'intento di convalidare i dati forniti dall'utente (es .: createE(some_actor, some_message) dovrebbe creare implicitamente produce - digita il bordo).

Approccio attuale

Una delle proprietà più belle di questo modello di dati è che il tipo di bordo è completamente determinato dai vertici a ciascuna estremità e, inversamente, una coppia di vertici può essere digitata in base al tipo e alla direzione di un bordo. Questo rende possibile fare cose come:

POST /:srcV/:dstV
{ edge JSON data goes here }

In tal modo, possiamo convalidare il contenuto dei dati JSON di bordo, assicurandoci che corrisponda al tipo di bordo creato implicitamente. Per maggiore chiarezza, :srcV e :dstV sono variabili che conterranno AGENT , MESSAGE o CHANNEL .

Tuttavia, mancano alcune cose:

1. come rappresento i vincoli
2. come devono essere trasmessi i vincoli su HTTP (parametri della query?)
3. come faccio a distinguere tra risorse e raccolte di risorse?

La domanda 2 è di particolare importanza perché voglio essere in grado di DELETE una raccolta di risorse basata su vincoli. Ad esempio, "rimuovi tutti i bordi del tipo publish per cui l'attore è iscritto a un determinato canale".

Questa è la prima volta che eseguo un lavoro non banale con REST, e mi sembra di incarnare questo modello di dati in qualcosa che potrebbe non adattarsi necessariamente. Pertanto, la mia domanda è duplice:

1. Qualcuno può indicarmi la giusta direzione? Qualche idea su come dovrebbe essere questa API?
2. Eventuali commenti, suggerimenti o critiche?

La mia comprensione è che softwareengineering.stackexchange è per fare "whiteboarding" di sorta, quindi spero che la comunità perdoni la natura aperta di questa domanda. Se ha bisogno di essere ristretto, per favore guidami con le domande e aggiorno di conseguenza.

Molte grazie in anticipo!

Note aggiuntive

1. È possibile (forse anche probabile) che la mia nomenclatura vertice / limite porti alla confusione. Sono aperto ai suggerimenti.

2. Alcune delle mie ipotesi (in particolare per quanto riguarda la teoria delle categorie) possono essere errate o errate. Le correzioni e le inquisizioni amichevoli sono ben accette!