Best practice Rails per controller RESTful metodi CREATE e UPDATE

Question

OK, sto cercando di capire le best practice per i metodi CREATE e UPDATE sia per i formati HTML che XML. Il codice predefinito per un controller generato dal generatore di rails non mi è chiaro.

Per il metodo CREATE, dato una buona salvare, il generatore dice di "redirect_to (@whatever)" per HTML e "render: xml => @whatever,: status =>: creato,: location = > @wother "per XML.

dato un cattivo salvataggio, il generatore dice a "render: action => 'nuovo'" per HTML e "render: xml => @ whatever.errors,: status =>: unprocessable_entity" per XML .

Tuttavia, per il metodo UPDATE, dato un buon aggiornamento, il generatore dice di "redirect_to (@whatever)" per HTML e "testa: ok" per XML.

E, dato un cattivo aggiornamento, il generatore dice a "rendere: action => 'Modifica'" per HTML e "render: xml => @ whatever.errors,: status =>: unprocessable_entity" per XML.

ho capito questo, e ha senso per me, e funziona bene - MA, ho due domande:

In primo luogo, per il successo creare e aggiornare, in formato HTML, perché "redirect_to (@whatever) "invece di" render: action => 'show' "? Capisco le differenze tra redirect e render, solo più curioso di sapere in che modo voi ragazzi lo fate e perché. Sembra che il reindirizzamento sarebbe un viaggio extra non necessario per il browser.

In secondo luogo, perché "testa: ok" su aggiornamento riuscito tramite XML, ma "render: xml => @whatever,: status =>: creato,: location => @whatever" su Riuscito via XML? Questo mi sembra incoerente. Sembra che un UPDATE di successo via XML dovrebbe essere lo stesso di un successo CREATE via XML. Sembra che tu abbia bisogno di un oggetto nuovo/aggiornato restituito per poterlo testare. Come lo fate ragazzi e perché?

Answer 1

avevo già scritto questo fuori quando Sam C ha risposto, ma qui è in ogni caso :-)

Per la prima parte - il motivo per cui, invece di reindirizzare il rendering? Due ragioni per cui posso pensare:

1) È coerente. Se hai eseguito il rendering dell'azione di show e l'utente utilizza il pulsante Indietro in un secondo momento, torna a quella pagina, l'utente vedrà un comportamento imprevisto. Alcune versioni di IE ti daranno qualche tipo di errore di timeout della sessione IIRC, altri browser potrebbero gestirlo in modo un po 'più elegante.

Lo stesso vale se l'utente ha messo in bookmark quella pagina e se ne torna in seguito utilizzando una richiesta GET - non vedranno l'azione di visualizzazione. La tua app potrebbe generare un errore o potrebbe eseguire il rendering dell'indice perché l'utente sta richiedendo un URL come http://my.app.com/users, che verrebbe mappato all'azione indice quando si utilizza una richiesta GET.

2) se il rendering l'azione spettacolo senza reindirizzamento a una richiesta GET e l'utente preme aggiornare il browser si ri-sottoporre la richiesta POST con tutti gli stessi dati, potenzialmente creando istanze duplicate di qualunque cosa sia si vuole creare . Il browser avviserà l'utente di questo in modo che possa abortire, ma è potenzialmente confuso e un inconveniente non necessario.

Per quanto riguarda la seconda parte della domanda, non troppo sicuro di essere onesto. La mia ipotesi è che, dal momento che stai già aggiornando l'oggetto in questione, ne hai già una copia, quindi non è necessario che venga restituita un'altra istanza. Detto questo, l'aggiornamento di un oggetto potrebbe innescare vari callback che modificano altri attributi dell'oggetto, quindi restituire l'oggetto aggiornato con tali modifiche potrebbe avere senso.

Answer 2

Per creare o aggiornare, redirect_to(@whatever) per cancellare il post, in modo che l'utente non venga reinviato dall'aggiornamento. Mostra anche l'url corretto nella barra degli indirizzi per il caso di creazione, che invia al percorso di raccolta (/ whatevers).

head :ok effettua una risposta minima all'aggiornamento, quando di solito si avrebbe già l'oggetto nella dom. Se si aggiorna la pagina dopo un aggiornamento, il metodo standard consiste nell'utilizzare le viste rjs per aggiornare gli elementi dom e renderizzare i partial.