Ho un'API RESTful, una delle risorse ha uno stato determinato collettivamente da più server, non tutti appartengono a noi. Una delle operazioni su questa risorsa dovrà modificare lo stato di più server. Il client invia una richiesta POST per eseguire questa operazione sul nostro server API e il nostro server API invia richieste agli altri server per soddisfare la richiesta.
A causa della natura di tutte le operazioni, non tutte le operazioni possono essere eseguite in un'unica transazione. Le API per i server partecipanti per lo più non supportano il commit a 2 fasi, ma la maggior parte ha una garanzia di idempotence, sebbene non tutte siano RPCish piuttosto che RESTful. Se durante questa operazione si verifica un errore, la risorsa viene lasciata in uno stato intermedio, ma il server dovrebbe essere in grado di ripetere le operazioni dal punto che ha interrotto per correggere lo stato della risorsa.
Sarebbe una cattiva idea o sarebbe in conflitto con i principi REST se il server riprende in modo trasparente le operazioni non completate la prossima volta che il client ricarica lo stato della richiesta (con un GET) piuttosto che richiedere al client di scoprire che la risorsa è in uno stato intermedio e inviare un'altra richiesta per risolvere la situazione prima di continuare qualsiasi altra cosa.
Da una parte, GET dovrebbe essere un'operazione sicura, ma d'altra parte, lasciare che GET risolva la situazione semplifica il client in quanto non deve occuparsi di questa situazione.
Nota che gli utenti interagiscono anche con gli altri server partecipanti direttamente (cioè non solo attraverso il nostro client) in modo che possano vedere alcuni degli effetti delle operazioni se una risorsa viene lasciata in uno stato intermedio.