{"id":2170,"date":"2016-02-16T00:00:00","date_gmt":"2016-02-16T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/keeping-post-and-get-separated\/"},"modified":"2021-05-17T18:34:45","modified_gmt":"2021-05-17T18:34:45","slug":"keeping-post-and-get-separated","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/development\/dotnet-development\/keeping-post-and-get-separated\/","title":{"rendered":"Keeping POST and GET Separated"},"content":{"rendered":"
\n

There are problems in server-side web development that have existed since the early days of the internet but which we as an industry have never solved in a definitive way that’s generally accepted. One of these issues is how to deal with error messages after a POST request, and more in general in how we should deal with return messages. I’m going to discuss and compare different approaches to dealing with return messages in ASP.NET MVC, but the problem exists regardless the actual platform. I’d say that the only web-based programming task unaffected by this problem is that of the entirely client-side, single-page applications where each interaction with the server is orchestrated from within the same environment and where a return or error message is the response to a synchronous or asynchronous request.<\/p>\n

Formalizing the problem<\/h2>\n

As an example, let’s consider a user that submits a form from within a web page. From the browser’s perspective that’s a plain HTTP POST request. The payload is created and the posted data is safely stored in the body of the packet. The server receives the request and handles it. Now assume the server is an ASP.NET MVC server. The request is mapped to a controller method and the controller method typically ends by selecting a Razor template for the view engine to render, filled with some retrieved data. The user receives some HTML and feels happy. Everything works just fine, so where’s the problem?<\/p>\n

This is probably the most common approach. It works, but is not free of snags. In particular, there are two potential problems. One is that the URL may not reflect the specific item of information being edited or created. The other is the repetition of the last action that was tracked by the browser. <\/p>\n

All browsers track the last HTTP command that the user requested and will reiterate that when the user hits F5 or selects the Refresh menu item. In this case, the last request is a HTTP POST request. Repeating a post may be a dangerous action because the POST is typically an action that alters the state of the system. To be safe, the operation needs be an idempotent operation (that is, it doesn’t change the state if executed repeatedly). To warn users about the risk of refreshing after a post, all browsers display a well-known message like the Google Chrome’s window you see in Figure 1.<\/p>\n

\"2368-Fig01.jpg\"<\/p>\n

Such windows have existed for years and didn’t prevent the spread of the web. Even so, they’re ugly to see and still liable to cause potentially harmful and unintentional user operations. It is not as easy as it may seem to get rid of those windows, though. To eliminate the risk of getting such messages, the entire flow of server-side web operations should be revisited but this, in turn, can end up creating new types of problems.<\/p>\n

The Post-Redirect-Get pattern<\/h2>\n

At its core, the problem here is that command and query operations-POST and GET in HTTP jargon-are not as clearly separated as they should be for the sake of software and design. Note that this problem of separating command and query is a very long-running issue in software engineering that dates back to the Eiffel language and Bertrand Meyer’s research of over two decades ago. Today, command and query separation is at the foundation of a strong and emerging architectural pattern-CQRS, short for Command and Query Responsibility Separation. As such, command and query separation is a much more general topic that goes well beyond the context of HTTP. Yet, keeping GET and POST actions clearly separated can only help. Enter the Post-Redirect-Get (PRG) pattern.<\/p>\n

The PRG pattern consists of a small set of recommendations aimed at guaranteeing that each POST command actually ends with a GET. It resolves the F5 ‘Refresh’ problem and promotes a neat separation between HTTP actions for command and for query. Let’s have a look at the some commonly-used code to display a view for a new user to register with a site.<\/p>\n

[HttpGet]\n[ActionName(\"register\")]\npublic ActionResult ViewRegister()\n{\n    \/\/ Display the view through which the user will register\n    return View();\n}\nTo register, the user fills out and submits the form. A new request comes in as a POST and is handed by the following code:\n[HttpPost]\n[ActionName(\"register\")]\npublic ActionResult PostRegister(RegisterInputModel input)\n{\n    \/\/ Stores the new record permanently\n    ...\n\n    return View()\n}\n<\/pre>\n
As written here, the      PostRegiste<\/strong>     r<\/strong>     <\/strong>method lacks any validation logic and returns to the same register form once completed. In case of unexpected results, or invalid input, it’s easy for the programmer to stuff error messages right in the view either via ad-hoc      ViewBag<\/strong> entries or through a view model type. Again, everything works just fine from a purely functional perspective. The only problem left is that, if the user refreshes the page after having successfully registered, then a new attempt is made which might originate some sort of an error message. <\/p>\n
Just one change is required to apply the PRG pattern to this code: instead of returning the view in the POST method, you redirect the user to another page. For example, you might want to redirect to the GET method of the same action.<\/p>\n
[HttpPost]\n[ActionName(\"register\")]\npublic ActionResult PostRegister(RegisterInputModel input)\n{\n    \/\/ Stores the new record permanently\n    ...\n\n    return RedirectToAction(\"register\")\n}\n<\/pre>\n
As a result, the last tracked action is a GET and this definitely eliminates the F5 issue. But there’s more. The URL displayed on the browser’s address bar is now a lot more significant. To understand this point, let’s assume that the same form is used to add new records or to edit existing ones. This means that the GET method may be given an ID. The code becomes as follows:<\/p>\n
[HttpGet]\n[ActionName(\"register\")]\npublic ActionResult ViewRegister(int? id)\n{\n    if (if.HasValue)\n    {\n       var model = _service.GetRegisterViewModel(id.Value);\n       return View(model);  \n    }\n    return View();\n}\n[HttpPost]\n[ActionName(\"register\")]\npublic ActionResult PostRegister(RegisterInputModel input)\n{\n    \/\/ Stores the new record permanently\n    var newUser = ...;\n\n    return RedirectToAction(\"register\", new {id = newUser.Id));\n}\n<\/pre>\n
Without the PRG pattern, the URL after a new user registered is still \/controller\/register. With PRG enabled, the POST method redirects to the view method and passes the ID of the newly created record. Hence, the new displayed URL is \/controller\/register\/id. And the last action to repeat is always a GET.<\/p>\n
Pros and Cons<\/h2>\n
Like any other pattern, PRG is not in  black and white. It’s just one common way of accomplishing some common tasks. PRG promotes the separation between commands and queries, keeps the URL cleaner and solves the long-standing problem of refreshing a page after POST. However,  PRG is not free of issues.<\/p>\n
By  separating HTTP, POST and GET with a redirect, you make for two distinct and unrelated requests. Unfortunately, in the context of the application, those two requests-POST and successive GET-are strictly related and should be treated as such. In particular, they should share some state information, specifically validation and error messages if any. The context of the POST action holds the results of input validation and any error messages that may have resulted from the execution of the intended task. But then the POST action redirects to refresh the view. How can you pass display information to the next GET? To help you better visualize the problem, consider a login form. If the credentials that have been provided are invalid, how would you display the canonical error message? <\/p>\n
In ASP.NET MVC, you have the following core options. <\/p>\n