HTTP GET setting internal data, still considered RESTful?

Question

As I understand it, a HTTP GET request should return the requested data and is considered RESTful if safe (read-only) and idempotent (no side effects).

However, I would like to implement a service to show new items since last visit using an URI of /items/userid/new, can that in any way be RESTful?

When returning the data, the items sent in response to the GET request should be marked as read in order to keep track of what is new. Marking these items will violate both the safe requirement and the idempotent requirement.

Does that mean .../new is never considered RESTful?

Answer 1

Very interesting question. I think the answer would be "depends on the implementation" since there are different solutions that would all meet the business requirement.

If every visit to the URL /items/userid/new by the same user modifies the DB records, then it's not a "safe method" and would not fit the commonly accepted REST pattern.

If you're filtering for the new items on the view, but without any corresponding DB changes with each GET call, then it would certainly be RESTful. For example:

/items/userid/new?lastvisit=2015-12-31

or

/items/userid/new?last_id=12345

or storing the list of viewed items on the client side would certainly qualify.