In our web application, I am allowing users to edit their profiles, using a simple single-page form (similar to the profile in SO).
I'm trying to decide whether to use the "post/redirect/get" pattern in this case.
On the one hand, after updating, users can refresh the profile page (or navigate to it using the back button) without any annoying browser messages asking whether they wish to resubmit their data.
On the other, this pattern requires a second request from the browser, and also requires the server to fetch the profile entity twice (once to update it, and then again to display it on redirect).
If we implement some type of database replication, there is the further problem that the second request may go to a different server, which may not have received the updates to the profile entity. This problem can be solved with Memcache or a similar strategy, but it adds further complexity.
The "post/redirect/get" also complicates displaying a confirmation message ("You profile changes have been saved"), as we now would need to store a flag that prompts the message to be displayed on the second request. Ideally, we want to keep our application as RESTful as possible.
What is the best way to approach this problem? Are there any other considerations which I've missed?
Always use Post-Redirect-Get. Period.
On the other, this pattern requires a second request from the browser, and also requires the server to fetch the profile entity twice (once to update it, and then again to display it on redirect).
Hardly measurable.
If we implement some type of database replication...
Then don't.
You rarely need this. Rarely. The bottleneck in almost all web transaction is the download from Apache to the desktop. Your application and database are not the bottleneck.
Don't use database replication until you can prove that the database really is the single slowest part of the transaction.
The "post/redirect/get" also complicates displaying a confirmation message ("You profile changes have been saved")
It's not a "flag". It's actually a queue of undisplayed messages. Your HTML interface involves sessions, and the message queue is a feature of the session object. HTML is not totally RESTful because -- well -- people expect sessions.
A pure REST version of this doesn't have a confirmatory message in the first GET.