I’d like to have a request returning some “analytics” as part of the request: most importantly, I’d like every GET requests to return the number of times the GET request has been called.
Is this fundamentally incompatible with the RESTful concept?
If it’s not fundamentally incompatible, how can I have my RESTful server return a different result for each GET request seen that, by definition of this problem, every GET requests means the next GET request must return something different?
If it’s fundamentally impossible to do in a RESTful way, should I drop REST or do I drop GET altogether?
P.S: This is my first question on SO so apparently I won’t be able to comment unless I hit 15 rep so it would be nice if commenters/answerers could upvote me so that I can be part of the SO community : )
There is no incompatibility with REST in principle here. You should consider the effect that a constantly-changing resource will not benefit from caching (assuming you don’t want the visit count to go stale). You should also consider that number to be constantly “eventually consistent”; that is, it will represent the count for some subset of the requests if you have lots executing in parallel. And you should also consider returning the count in an “X-Visit-Count” header instead of the main payload to make the feature more generic and avoid polluting whatever payload you do return, and potentially allow for better caching. But there’s nothing at all “against REST” for a resource to return a different representation each time you GET it.