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

Question

I'm trying to understand REST. Under REST a GET must not trigger something transactional on the server (this is a definition everybody agrees upon, it is fundamental to REST).

So imagine you've got a website like stackoverflow.com (I say like so if I got the underlying details of SO wrong it doesn't change anything to my question), where everytime someone reads a question, using a GET, there's also some display showing "This question has been read 256 times".

Now someone else reads that question. The counter now is at 257. The GET is transactional because the number of views got incremented and is now incremented again. The "number of views" is incremented in the DB, there's no arguing about that (for example on SO the number of time any question has been viewed is always displayed).

So, is a REST GET fundamentally incompatible with any kind of "number of views" like functionality in a website?

So should it want to be "RESTFUL", should the SO main page either stop display plain HTML links that are accessed using GETs or stop displaying the "this question has been viewed x times"?

Because incrementing a counter in a DB is transactional and hence "unrestful"?

EDIT just so that people Googling this can get some pointers:

From http://www.xfront.com/REST-Web-Services.html :

4. All resources accessible via HTTP GET should be side-effect free. That is, the request should just return a representation of the resource. Invoking the resource should not result in modifying the resource.

Now to me if the representation contains the "number of views", it is part of the resource [and in SO the "number of views" a question has is a very important information] and accessing it definitely modifies the resource.

This is in sharp contrast with, say, a true RESTFUL HTTP GET like the one you can make on an Amazon S3 resource, where your GET is guaranteed not to modify the resource you get back.

But then I'm still very confused.

Answer 1

Just because the page is accessed via a GET, doesn't mean that there isn't a way to increment the counter. You could use an AJAX POST for example.

I also think that this kind of "passive" transaction could probably be safely ignored. There's a big difference between visiting a URL and deleting an object somewhere, and visiting a URL and incrementing a visit counter. I'd be interested to hear other views on the subject though.

Edit: I think Håvard S and I are basically in agreement, that a GET that triggers a counter may be technically un-RESTful, but isn't something worth worrying about.

Answer 2

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.

Answer 3

One point you'd need to look out for: GET requests can be triggered by bots, e.g. search engines. These would skew your statistics if you don't allow for them.

Answer 4

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

Answer 5

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.

Answer 6

GET is only safe and idempotent with regards to the resource identified by the request - that is all the client needs to, and should, be concerned with.

The easiest way to think about this is to consider any mechanism performing such counts as an intermediary (i.e. you are leveraging the layered constraint) which monitors the request/responses and updates some other view count resource, rather than the actual resource itself.

Answer 7

A POST is for sending information the client supplies to the server. That is not happening here, so POST is unnecessary.

In order to maintain the statelessness of the HTTP interaction (which I believe is the purpose of REST), it is not necessary for GETs not to cause any state changes; but what is required is that it doesn't hide states from the client; i.e. any amount of state with future consequences for the HTTP interaction will need to be encoded into the URL space so the client can use it to address future requests.

The counter is part of the state iff its value will affect future interactions - for instance, if after every millionth increment, the "please book a bus tour on which we will try to sell you real estate property in Orlando" subsystem kicks in. REST basically says that in such cases, it should be part of the URL space, so the state can be maintained explicitly as part of the addressing - for instance, you might generate a GET to a URL to which a string ?counter=$cnt is appended (with $cnt the value of the counter).

If not, it is just part of the view - there is no reason for the client ever to feed it, or any other information based on it, back to the server, so there is no need for it to be present in a URL (or anywhere else). You display it and discard it.

Answer 8

One more thought:

I think the "read count" must not be incremented. Think of all sorts of bots/crawlers/caching applications that do not represent a "read". Instead there could be some way to trigger a real read (by the client).

/question/2363294 --> Get returns the question but does not increment the counter /question/2363294/readCount --> Get returns the current read count /question/2363294/readCount --> Post updates the read count

Then my nice client app just posts the read, as soon as I realy have taken a look at it. And not when it has been downloaded, e.g. because of prefetching ...