La mia domanda riguarda le migliori pratiche di aggregazione o raggruppamento delle API REST. Ho uno scenario in cui ci sono molti diversi fornitori, origini dati, ecc. E penso che raggruppare le API REST avrebbe molto senso mantenere il sistema mantenibile.
Ho molti scenari in cui ci sarà una singola chiamata API che innesca molte altre chiamate API (simili) per creare la stessa entità in un altro sistema . Ad esempio per un esempio di entità "utente" :
- API REST chiamate front-end: PUT ... / user
- Quello che immagino è che il codice in ascolto sull'API sopra farà quindi più chiamate REST PUT per dire vendorA / utente, vendorB / user, vendorC / user, internalSystemA / user, internalSystemB / user, ecc.
In questo modo:
+-------------------+
+--------+ PUT +-----------+ CALL | Vendor A API |
| | +-------> | user +--------> | |
| | | +-----------+ +-------------------+
| | |
| Front | PUT +--------++ PUT +-----------+ INSERT +-------------------+
| End +------> | user +------> | user +--------> | Internal System |
| | +--------++ +-----------+ +-------------------+
| | |
| | | +-----------+ CALL +-------------------+
| | +-------> | user +--------> | Vendor B API |
+--------+ PUT +-----------+ | |
+-------------------+
+ +
+---------------------------------+
Internal REST APIs
Si noti che l'entità di esempio non deve essere "utente", ci sono molte entità che avranno una controparte sulle API del fornitore.
I fornitori in questo scenario offrono funzionalità diverse. Ma potrebbero esserci più fornitori che offrono la stessa funzionalità (e l'utente sceglierà il fornitore che desidera utilizzare). Per semplicità, diciamo che le funzionalità di esempio sono
- Procurement,
- Risorse umane,
- Gestione,
- pagamento.
Qual è la migliore pratica per raggruppare e nidificare le API REST in uno scenario del genere? È una buona idea raggrupparli per venditore o dovrebbero essere raggruppati come funzionali o per entità aziendale? Come sarebbe l'URL?
