Understanding REST: is GET fundamentally incompatible with any "number of views" counter?

What matters is that from a client point of view GET is safe (has no side effects) by definition and that a client therefore can safely call GET any number of times without considering any side effect that might have.

What a server does is the server's responsibility. In the case of the view counter the server has to make the decision if it considers the update of the counter a side effect. Usually it won't because the counter is part of the semantic of the resource in the first place.

However, the server might decide NOT to increment the counter for certain requests, such as a GET by a crawler.

Jan

IMO avoiding a statistics update in a GET request because "someone said so" is being dogmatic about ReST. Do what is pragmatic. If that involves updating a counter when responding to a GET request, so be it.

To elaborate further, what is really important (and the reason the advice is there) is that the resource a consumer is accessing is not updated or altered in any manner when the consumers intent is to read it. However, updating other data, in particular stuff like logs and statistics, is not a problem. In short, reading a resource should not have side-effects on the resource being read.

EDIT: To answer your case of a self-incrementing counter, ask yourself what the context you apply is. Clearly, if you define a resource called counterThatIncrementsItselfWhenBeingRead, then it either:

• Breaks ReSTfulness since a read-incrementing counter is a self-contradictory resource if the only rule is that GET can never have side-effects, or
• Is just fine given a different context, where you for instance take a very short resource lifespan into account, and choose to view the increment as something that happens after you have read the resource (or more generally at the resource owner's discression)

Regardless of the resolution you choose to apply, the issue is really about what the expected behavior is. IMO, a counter that increments itself when being read should be incrementing itself when being read. I still access a representation of a resource, albeit one with a very short lifespan, which I know will be changed an instant after I have read it. There's nothing non-ReSTful about that.

You are mixing a couple of issues here. A single request to a REST interface CAN trigger a back-end transaction. However, that transaction must start and finish within the scope of the single request.
What a REST interface should not do is have multiple independent requests participate in the same back-end "two phase commit" transaction.

The second issue is whether a GET request can do updates. As Jan points out in his answer the GET is allowed to have side effects as under certain conditions. He says it much better than I could so read his answer for why.