How should I represent a UI state change in the URL?

Question

My web application has a UI. Some aspects of the UI can be changed (e.g. the language, the theme, the text size). As a concrete example, let's assume that I have a "theme" dropdown box available on every page.

Now, when a user changes the theme, the current page should reload with the new theme, and the new theme should be used for all subsequent page calls. In other words, I want to (a) change some server-side state (the session variable containing the theme name) and (b) reload the page.

I know how to implement this. In fact, I know more than one way to implement this, and this bugs me. I want to find the best way to implement this, and since best is subjective, I want to identify the advantages and drawbacks of both options (and maybe learn about alternative solutions that I didn't even think of).

---

Here is solution 1:

• I add the new theme name as a query parameter (i.e. http://example.com/show_orders?customerId=2 becomes http://example.com/show_orders?customerId=2&changeTheme=dark) and reload the page.
• A generic server-side handler checks for the changeTheme parameter, updates the state and then execution passes on to the specific handler (show_orders), which ignores the unknown changeTheme parameter.

What I don't like about this solution is that

• page-specific parameters (customerId) and site-specific parameters (changeTheme) are mixed and
• "state-changing" parameters are in the URL: If the user sends the URL to a colleague directly after changing the theme, calling the URL will also cause the colleague's theme to change. I don't know if there is a specific term for this, but if just "feels wrong" to have a GET request to a resource called show_orders change something. (Feel free to correct me, if my gut feeling is wrong here.)

---

Here is solution 2:

• I call a dedicated URL for changing the theme and pass the original page as a parameter, i.e. http://example.com/change_theme?newTheme=dark&redirectTo=%2Fshow_orders%3FcustomerId=2.
• The change_theme handler changes the session state and then redirects (HTTP 302) to the original URL as defined in the query string parameter.

What I don't like about this solution is that

• I am redirecting back and forth, which might affect performance, and
• I am redirecting to a user-supplied value, so I might need to take extra precautions w.r.t. security.

---

Today, I implemented solution 1 and I am considering to change it to solution 2, for the reasons outlined above. Is this a good idea? Are there pros and cons that I have missed? Is there some superior solution 3, which is well-established best industry practice? If yes, what problems does it solve that options 1 and 2 have?

Answer 1

Solution 2 is an well-established practice in the industry, especially when dealing with login screens.

The scenario is then:

• you navigate to an URL for which authentication is needed
• the server redirects you to a login page, but also marks the original endpoint either in the URL or in a hidden form field
• after successful authentication, you are redirected to the page you originally requested.

Also, the pattern POST - redirect - GET is very commonly used when users submit a form to avoid double submissions when the user refreshes the browser page, so the redirect can't have that much of a performance penalty.