L’architettura RestFULL è considerata nociva

Oggi mi sono imbattuto in questo interessate articolo che spiega un po’ tutti i problemi attuali dell’architettura restfull, che fino ad oggi ho sempre sostenuto tenendo alta la bandiera.

Leggendo le motivazioni, mi sono però ritrovato perfettamente in alcuni problemi che ad oggi questa architettura soffre. Gli elenco brevemente (maggiori dettagli li trovate nell’articolo):

• Non esiste un formato di compressione. Infatti, anche se il json può risultare comunque leggibile all’occhio umano , non sempre è necessario che i dati scambiati debbano avere questa particolare caratteristica. Dopo tutto quando lanciamo la nostra applicazione in produzione non ne abbiamo assolutamente la necessità. Passare da jSON ad XML sicuramente è stato un passo in avanti per snellire la struttura dei messaggi scambiati ma possiamo sicuramente ottimizzare meglio questo passaggio comprimendo i dati in binario. Ad esempio si può pensare di utilizzare un servizio di messaggistica binario come Protocol Buffers offerto da Google.
• Non esistono dei contratti/schema che stabiliscono come gestire i messaggi da inviare/ricevere. Esistono comunque strumenti di supporto che ci aiutano a definire le specifiche di utilizzo delle nostre api come swagger.io
• Non esistono specifiche standard per definire la ricerca, l’ordinamento e l’impaginazione delle nostre api ma solo linee guide sul quale vengono fatte tante proposte discordanti fra loro.
• I web services restfull sono CRUD-oriented e non business o transaction-oriented. Questo ci costringe a mappare i termini del nostro domini in semplici operazioni di creazione/aggiornamento/cancellazione. Questo è estremamente semplificativo e non sufficiente a rappresentare il nostro dominio applicativo.
• Gli errori di logiche di business tipicamente dovrebbero essere codificate in errori http 4xx. Ma questi non sono stati creati per mappare errori di dominio. Quindi ci ritroviamo ogni volta a fantasticare sui giusti codici di errore che più riteniamo opportuni: record duplicato ? 409… email errata ? facciamo 400… ma cosa succede se il cliente non ha il saldo sufficiente per acquistare un prodotto ?. Per raggirare questo problema lancio sempre un errore 400 e nella risposta inserisco maggiori dettagli sull’errore con una struttura dati realizzata ad hoc: field, message e error code.

In sostanza, il problema principale dell’architettura RestFULL e che non ci sono standard ma solo linee guide spesso discordati tra loro e la mancanza di standard significa che tutti possono chiamare i propri webservices REST-FULL.

Ad ogni modo questo articolo non vuole bannare l’uso dell’architettura restfull ma solo lanciare qualche riflessione a cielo aperto e magari a valutare alternative quando ci troviamo in particolari contesti. Ad esempio se le perfomance di banda sono un requisito fondamentale optiamo per soluzioni che non portano a costi di compressione/decompressione oppure se quando inviamo un messaggio non c’è bisogno di attendere la risposta potremmo pensare di adottare una soluzione di broker di messaggi come rabbitmq.