La mia organizzazione si sta spostando su un'architettura REST e ho un piccolo problema da risolvere.
Ho due sistemi di amministrazione che ospitano prodotti / risorse dello stesso tipo e quindi utilizzo un modello comune di una risorsa di raccolta di aggregatori con ogni elemento del payload contenente un collegamento HATEOS alla risorsa dell'istanza di quell'elemento. Ecco il modello URI nel disegno corrente.
URI della risorsa di raccolta
v1/line-of-business/product-line/business-process/product-resources
URI risorsa istanza
v1/line-of-business/product-line/business-process/product-resources/resource-uuid/product-resource
Utilizzando questo modello URI, la risorsa effettuerà una chiamata a un servizio uuid Mgmt per decrittografare l'ID risorsa da utilizzare come parametro di query nel back-end per creare l'oggetto risorsa. Il problema è che l'API della risorsa di istanza non ha alcun contesto noto su quale sistema di amministrazione è ospitata la risorsa. Un paio di altri flussi di lavoro hanno fornito i seguenti suggerimenti per risolvere questo problema e indirizzare la risorsa di istanza al sistema di amministrazione corretto:
- sistema di query A prima cosa e se il risultato è vuoto, quindi effettuare una chiamata al sistema B ma siamo d'accordo che questa è una cattiva pratica che non voglio implementarla come soluzione strategica.
- Crea un servizio di convenienza che cercherà il sistema di amministrazione e in base al percorso dei risultati fino al livello dati appropriato. Questo è un sacco di traffico extra DB.
FYI, il sistema A andrà in pensione ma non per alcuni anni e sappiamo tutti come vanno questi piani. Potrebbe essere intorno per molti anni quando iniziano a stimare il costo della conversione e del ritiro dei dati. Utilizzando la logica di routing di cui sopra, se aggiungiamo un terzo sistema di amministrazione (attività che guardano a opzioni di distribuzione di terze parti, ospitate on e off prem), dovremmo modificare la nostra logica di routing per controllare anche il nuovo sistema.
Non riesco a trovare alcun esempio di questo problema, ma so che è stato risolto molte volte. Le soluzioni di ricerca / routing di cui sopra sono comuni? Anche se la risposta è sì, è una buona pratica? Quali sono le migliori pratiche da risolvere per questo? Sono nuovo agli schemi di progettazione REST e con la mia esperienza limitata ho proposto la soluzione in basso ma non è stata ricevuta bene:
URI risorsa istanza
v1 / line-of-business / linea di prodotti / processi di business / product-risorse / {admin-sistema} / resource-uuid / prodotto-risorsa
Ho pensato aggiungendo il sistema di amministrazione come parametro di percorso nell'URI, non dobbiamo effettuare chiamate DB aggiuntive. Il mediatore delle risorse può indirizzare al livello dati appropriato in base al parm del percorso. Questo ci consente anche di aggiungere nuovi sistemi di amministrazione al volo. Non funzionerebbe? TIA