I was reading through the HTTP request docs and I saw this:
Each [HTTP request] implements a different semantic, but some common features are shared by a group of them: e.g. a request method can be safe, idempotent, or cacheable.
Do I have to implement these features? Specifically, what if I keep track of when my clients last requested some information, which would make my GET request change server state? Or if I used a PUT request to append data rather than replace, making it not idempotent? The docs specifically say to not do the above 2 things:
Requests using GET should only retrieve data.
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property
Broadly, yes.
For example, you should use POST or PATCH in order to append.
Your GET can maintain state for the client (although that's probably not scalable), but the response has to be the same as long as the URL & headers are the same.
Basically, clients will make assumptions based on the method. And it's not just clients, it's also whatever proxies are between you and your clients, e.g. CDNs, browser proxies etc..
Some libraries might assume that they can retry idempotent operations like GET and PUT. This is important in cases where your server has processed the request, but the response didn't make it to the client on time.
Many clients, including browsers, assume that GET can be returned from their local cache, so they won't even talk to your server. There are cache control response headers to help with that.
If you need to maintain client state, it's possible that HTTP is not the right protocol for you to use, HTTP aims to be scalable, and maintaining client state is an impediment to scalability.