Spero di aver scelto la comunità giusta per questo (non c'è architettura software / design di uno)!
Vorrei chiederti delle considerazioni pratiche sulle API RESTful (e modelli di progettazione simili come per quella materia) nel contesto di complesse operazioni lato server / logica aziendale.
Poche cose da tenere a mente:
- So che REST non è l'unico modo per andare, né il proiettile d'argento
- Non sono riuscito a trovare alcun modello / pratica di progettazione che mi permettesse di mantenere l'API strutturata (come fa REST) e di renderla sensata per ciò che devo fare.
Penso che sarà molto più facile se ti faccio un esempio, quindi eccoci qui: Sto affrontando una logica aziendale che si estende su più passaggi. I passaggi sono:
- L'utente effettua varie scelte e le invia (diciamo che stanno usando il modulo HTML).
- Queste scelte sono convalidate per essere entrambe aggiornate (con lo stato del database, ad esempio alcune opzioni potrebbero non essere più disponibili al momento della loro presentazione) e contro se stesse (perché è possibile avere solo determinate combinazioni di opzioni messe insieme ).
- Se tutto va bene, vengono effettuati alcuni aggiornamenti del database (ad es. per creare un pre-ordine di merci limitate per quell'utente).
- Viene quindi fornita all'utente la risposta (lascia che sia il modulo HTML per ora) contenente informazioni che consentano loro di completare un altro passo facendo ancora più scelte - diciamo che dovrebbero scegliere il loro metodo di pagamento per merci precedentemente prenotate.
- Presentano nuovamente le loro scelte, in risposta ricevono informazioni che consentiranno loro di completare il pagamento.
- E qui inizia a diventare brutto ...
Fino al punto 5 sono in grado di identificare le risorse REST, ecc. Diventa davvero difficile elaborare ulteriori passaggi. Perché? Perché una volta che l'utente ha completato il pagamento (in un modo o nell'altro, non importa), riceverà l'URL del mio endpoint API che dovrebbe verificare il pagamento, elaborare il pre-ordine nell'ordine effettivo e restituire conferma all'utente. Che in caso di REST dovrebbe essere (la conferma) una risorsa. Questo va bene, ma avendo in mente il processo di trasformare il pre-ordine in un ordine significa creare più risorse di tipi diversi, significa che "nascondiamo" queste risorse all'utente.
Fondamentalmente, ci sono un sacco di cose che accadono sotto il cofano e dovrebbero probabilmente essere restituite in una conferma. Il problema è che non c'è alcuna conferma da nessuna parte nel database.
Ma bene, passiamo alla domanda: c'è qualche schema di progettazione, struttura, architettura più adatta a questo tipo di problemi?
Note a margine:
- Ho detto che non ci sono conferme nel database - Ho un'app monolitica che mi piacerebbe trasformare in un'applicazione basata su API per disaccoppiare back-end e front-end.
- Sono anche preoccupato per le prestazioni. Credo che alla fine questo potrebbe essere fatto in modo RESTful (sebbene possa essere difficile senza mantenere lo stato), ma ciò significherebbe rendere l'API semplice per problemi complessi, con il risultato di molte chiamate API per ottenere lo stesso effetto.
Modifica
Un'altra cosa che mi riguarda e che mi fa andare contro l'API RESTful è che richiederebbe che queste chiamate API multiple completassero l'intero processo agendo sulle risorse, il che significherebbe che qualsiasi app client che utilizza questa API dovrebbe implementare nuovamente la stessa logica invece di incapsulare questa logica sul lato server