A GET should never change data on the server- use a POST request for that

I heard this recommendation countless times over the internet and always try my best to conform. But how should I implement UTM tracking, while staying compliant to this requirement at the same time? For example, http://example.com/?utm=r3ct59 by appending utm url parameter to URL, I want to track from where my users are coming from. Shouldn't I update database when client sends GET request to this url? What are alternatives?

  • 1
    Do you understand why that recommendation is made, and do you think those reasons are critical when implementing user behaviour tracking? Commented Aug 24, 2021 at 19:26
  • yes, I read about the reasons. Let's say they are not critical in this case. Is it enough for breaking the mentioned rule? What should I do when they are critical? Commented Aug 24, 2021 at 19:32
  • 2
    Do you think the reasons are critical in the user tracking case or not? If they're not, then you (hopefully) understand already why you can break the rule. If you think they are critical, then you probably need to explain why in your question. Commented Aug 24, 2021 at 19:38
  • they're not critical I think. In addition, this method is not reliable, one user can send request to the same link multiple times or edit utm value and can easily distort my statistics. But I see such url parameter in many links (e.g. most of the urls from slack contain something like source=slack). What I'm wondering is that why this rule exists, while everyone is breaking it at some cases? Commented Aug 24, 2021 at 19:45

1 Answer 1


The key thing is that a GET request should never change the application state from the perspective of the end user - however it can make changes on the backend that are not visible to the user. RFC7231 discusses what the restrictions on GET (and other "safe" methods) are:

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.

This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access log files at the completion of every response, regardless of the method, and that is considered safe even though the log storage might become full and crash the server. Likewise, a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account.

Just like every GET request made to you site will result in an entry being written to your log files, it's also perfectly acceptable for you to write an entry to your database for specific GET requests. However, in doing this, you might run into some unexpected requests being made with the UTM tags, such as:

  • The user clicking the back button in their browser or refreshing the page.
  • The user bookmarking a page with a UTM tag.
  • A spider (such as Googlebot or a security scanning tool) crawling your website.
  • A browser pre-fetching links on the page.
  • The contents of the page being cached by the user or an intermediate proxy.

This could result in duplicate or spurious entries in your tracking database, and then are your problem to deal with, not the fault of your users.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.