Non dovresti mai (come mai e poi mai) bloccare alcuna risorsa mentre aspetti un'interazione con l'utente.

Ad un certo punto alcuni dei tuoi utenti decolleranno per un lungo weekend lasciando bloccati alcuni record vitali.

Ah, ma non lascerai che ciò accada perché hai qualche schema di risoluzione time-out / deadlock intelligente; poi ad un certo punto questo andrà terribilmente storto e un utente che ha ricevuto un bel messaggio "il tuo widget è stato ordinato" urlerà all'help desk chiedendo di sapere perché il suo widget non è stato consegnato.

La maggior parte delle persone può gestire il messaggio "mi dispiace che un altro utente abbia appena ordinato questa parte".

L'utilizzo dei token è molto comune nelle API, questi token vengono solitamente inviati come intestazione e hanno un ciclo di vita chiaro. Pensa ad esempio OAuth.

Indipendentemente dal linguaggio di programmazione o dal framework, le API REST sono simili.

Posso pensare a diversi scenari in cui si desidera limitare la concorrenza, due dei quali sono:

1. Più client che aggiornano le stesse risorse come una riga del database. Ad esempio: due richieste simultanee, una elimina un record e l'altra tenta di aggiornare lo stesso record. A seconda del tuo database e del modo in cui lo hai impostato, potresti ottenere un blocco sui record o un'operazione non valida poiché i dati saranno diversi o non esisteranno.

2. Un superutente o amministratore che esegue azioni speciali con l'API.

Che cosa fare in questi casi?

1. Utilizza le transazioni nel database, singleton, blocchi e meccanismi simili per sincronizzare l'accesso alle risorse.

2. Il token potrebbe funzionare, penso che sarebbe meglio se non memorizzassi le informazioni sul client, solo sul token stesso. In un solo passaggio è possibile convalidare l'utente e assegnare il token. Quindi convalida solo che il token è vivo ed è valido. Utilizzare un token che può essere decodificato per ottenere informazioni aggiuntive. È possibile memorizzare se si tratta di un token speciale e consentire solo alla volta. In questo modo convalidi il token, non l'utente.

Spero che questo aiuti.

Il REST da solo è troppo primitivo, davvero. Puoi iniziare con REST, ma alla fine, la tua ricca applicazione avrà bisogno di query con join e aggiornamenti con le transazioni. Ogni sviluppatore che tenta di aggiungere queste cose da solo sarebbe soggetto a errori e inconsistente. Fortunatamente, esiste uno standard emergente chiamato OData che fa proprio questo. Si sovrappone a REST e fornisce (1) il linguaggio di query che consente i join semplici utilizzando le proprietà di navigazione (senza dover esporre chiavi esterne) e, (2) l'elaborazione batch che include i set di modifiche atomiche.

Vedi qui per (1) link , e,

Vedi qui e per (2) link