Question: In the field of web development, is it good practice to do a [POST/Redirect/GET](http://en.wikipedia.org/wiki/Post/Redirect/Get) when fields in a form submission are invalid, as well?

Typically, no sensitive transaction would have taken place, in this event. However, can an argument be made that, nonetheless, it is still good practice to utilize the POST/Redirect/GET pattern?

Answer: 
From a REST perspective the web conversation should go like this

> 
> GET /example
> 
> 
> 200 OK - contains empty form HTML
> 
> 
> 

The user fills in the form

> 
> POST /example
> 
> 
> formfield1=ok
> 
> 
> formfield2=bad
> 
> 
> 400 BAD REQUEST - contains populated form HTML with errors
> 
> 
> 

The user identifies the problem with the form submission and fixes it

> 
> POST /example
> 
> 
> formfield1=ok
> 
> 
> formfield2=fixed
> 
> 
> 201 CREATED - contains HTML with success message and onward links (also Location header for REST clients) or 200 OK and 204 NO CONTENT are acceptable
> 
> 
> 

There is no need to introduce a redirect, and it would break the semantics of the conversation to do so.
I would say generally not, on the grounds that when a form is POSTed with invalid fields, what you normally want to serve in response is the same form with the same field population, plus some error messages. This would be onerous to perform via POST/Redirect/GET - how would you ensure that the page returned by the GET already had the user's entries in the form fields?