Como os erros do lado do servidor são tratados no padrão de postagem/redirecionamento/obtenção?

Question

Para o caso de uso bem-sucedido, o fluxo de trabalho Post/Redirecion/Get (PRG) é bastante simples: simplesmente redirecionar (lado do cliente) para a página desejada. Mas e os casos em que os erros são encontrados durante a validação do lado do servidor e queremos preservar as entradas quando exibirmos a página de entrada novamente?

Até onde eu sei, existem duas abordagens: basta renderizar a página de entrada após o envio do Formulário Post (ou seja, sem redirecionamento) durante os erros (desconsiderando assim o padrão PRG); Ou, redirecione para a página de entrada e armazene as entradas anteriores em algum lugar em que possa ser recuperado posteriormente (por exemplo, sessão), durante a renderização. Ambos têm desvantagens: no primeiro, somos apresentados com o padrão PRG de problemas nos ajuda a evitar (por exemplo, favorável à marcação, envio duplo); A segunda abordagem leva a obtimentos inconsistentes (o primeiro Get encontrará as entradas armazenadas, o número subsequente pode não). Existem outras alternativas para as mencionadas aqui? Espero que os insumos da comunidade sobre como este caso é melhor tratado.

Answer 1

Normalmente, faço isso da primeira maneira que você descreve - redireciona apenas no caso de um envio bem -sucedido. É difícil ver um caso de uso real para marcar um formulário contendo dados inválidos; Por outro lado, muitas vezes faz sentido marcar uma página de confirmação (após o envio bem -sucedido).

Answer 2

Se o URL sendo usado para preencher o formulário é aquele para o qual o formulário posta, acho que não há um problema. Se a entrada for válida, redirecionar e obter. Se for inválido, redisplay o formulário preenchido. Dessa forma, a interação se parece:

GET  /your-url => blank form
POST /your-url (success) => Redirect => GET /success-url
POST /your-url (failure) => filled-in form

Answer 3

A questão mencionada de favoritos está afetando as duas abordagens, você não pode realmente marcar algo que depende de alguns dados temporários preservados no servidor.

E a submissão dupla não é realmente um problema se você garantir que, se a validação falhar, você não salva nenhum dado (ou seja, todos os envios com dados falhados são a solicitação idempotente).

Portanto, o PRG apenas no sucesso é uma abordagem muito limpa.

Answer 4

Como as outras respostas dizem, use apenas o padrão de postagem/redirecionamento/obtenha na validação bem-sucedida do servidor. Quando um formulário é inválido, basta responder à resposta diretamente, com mensagens de erro.

Para usabilidade, você deve ter certeza de que A validação do lado do cliente é excelente, essa é uma boa ideia de qualquer maneira, como usuários gostam de feedback imediato. Use JavaScript, ou o Novos recursos de formulário HTML5, tais como o required atributo ou o maxlength atributo ou type="email" atributo e assim por diante.

É claro, você ainda deve ter validação do lado do servidor por segurança e por degradação graciosa.

Answer 5

Se você estiver usando o ASP.NET MVC, existe outro método que pode ser usado para a situação de falha do post ->. Está coberto em #13 deste artigo: ASP.NET MVC MELHORES PRÁTICAS (PARTE 1).

Se você implementar esse método, você pode sempre Redirecionar após uma postagem, mesmo que a postagem resultasse em uma falha.