Vincolo univoco in un'architettura RESTFul

Question

Con 15 anni di esperienza nello sviluppo del software client-server (ed i suoi problemi intrinseci) sto ancora cercando di cogliere il concetto di apolidia in un'architettura RestFul.

Supponiamo di avere un'interfaccia generica per inviare oggetti business al mio servizio REST. Ad esempio Risorse utente. La mia risorsa utente dovrebbe avere un vincolo sull'unicità del suo indirizzo email. La mia prima reazione sarebbe quella di utilizzare le strutture del database sottostante per "garantirne" questo. La seconda reazione sarebbe introdurre un meccanismo di blocco o transazionale.

Ma il mio collega Restafarian risponde: "No!" Il client dovrebbe verificare se l'e-mail per il nuovo utente è unica e si dovrebbe accettare il fatto che c'è una piccola finestra di tempo in cui è possibile inserire un indirizzo email duplicato. L'applicazione client dovrebbe essere in grado di gestire questo conflitto.

Questo a sua volta va contro tutto ciò che ho imparato e non mi sembra affatto naturale. Per favore chiariscimi ...

Answer 1

Non vedo alcun motivo per non restituire l'appropriato HTTP code: 409 Conflitto. Questo può essere restituito in caso di errori dal tuo database.

È utile, per motivi di usabilità, verificare se l'indirizzo di posta elettronica è univoco prima di inviare la richiesta, in quanto è possibile richiedere all'utente (e disabilitare l'invio) di correggere il problema. In ogni caso, la verifica lato server è ancora consigliata.

Answer 2

Questo non ha nulla a che fare con l'assenza di stato del protocollo. L'apolidia dice solo che il server non dovrebbe essere lo stato relativo alla sessione di salvataggio (http://en.wikipedia.org/wiki/Stateless_protocol).

Nel tuo caso, le risorse utente non sono state di sessione: sono risorse permanenti memorizzate sul server ed esposte. Non c'è motivo per l'apolidia per forzare il client a fare questo controllo (recuperando e controllando iterativamente tutte le risorse utente), e ha più senso farlo fare al server. Se questo controllo viene eseguito dal server come parte del POST di una nuova risorsa utente o esiste una risorsa separata che abilita questo controllo, in pratica non fa alcuna differenza poiché il server sta eseguendo questo controllo in entrambi i casi. Se si utilizza una risorsa separata per verificare innanzitutto se è OK POSTARE un nuovo utente e quindi effettuare una nuova richiesta per eseguire effettivamente il POST, allora esiste la possibilità di duplicare gli indirizzi e-mail. In tali casi, il comportamento previsto è che il server notifica al client che la richiesta POST non è riuscita (utilizzando un codice di risposta HTTP appropriato, proprio come farebbe per la prima richiesta con cui il client ha verificato che l'e-mail è OK).

In breve: il server esegue il "controllo" e il client deve essere in grado di gestire le situazioni in cui il server notifica che il controllo non è riuscito.