GET vs POST
Use the following to determine if you should use GET vs POST when implementing Page Actions.
| Consideration | GET | POST |
|---|---|---|
| Browser Back Button | ✅ Works naturally - returns to previous filter state | ⚠️ Shows "Confirm Form Resubmission" dialog |
| Browser Refresh | ✅ Re-executes query silently | ⚠️ Shows "Confirm Form Resubmission" dialog |
| Bookmarkable | ✅ Yes | ❌ No |
| Shareable URLs | ✅ Yes | ❌ No |
| URL Visibility | Parameters visible in address bar | Parameters hidden |
| Caching | Browser may cache | Not cached |
| Idempotent | ✅ By convention, GET = read-only | POST = implies modification |
The back/refresh issue is significant. With POST, users hitting back or F5 get an annoying browser dialog asking to resubmit the form. This is jarring for a simple filter that doesn't modify anything.
Semantic correctness: GET is for retrieving data, POST is for submitting data that causes a change. A filter is purely a read operation.
One more postback wrinkle, on the UX side: a POST that reloads the page resets the scroll position to the top — on a long or multi-step page that gets annoying fast. The PostbackScroll element (see Page Widgets) is an opt-in fix that restores the scroll position, or scrolls a wizard's newest step into view, after the reload.