0

I would like to record user actions on my website, not only on POST requests, but on GET requests as well. For example, suppose the user tries to search for a city with the following GET request:

/search_city?name=greenville

This request would return a list of cities with the name "greenville". I'd also like to save this keyword to the server, as the "search history" for a user. I'm planning to just do the save this information during the processing of the GET call.

Is this a violation to RESTful principles? If yes, how do I do this the right way?

Bryan
  • 3,220
  • 3
  • 26
  • 31

2 Answers2

3

I see this kind of audit logging as an invisible side-effect. If the next person to call

/search_city?name=greenville

still gets the same answer then your GET is valid. A similar case would be some kind of cache building, the caller of GET doesn't (need to) know that you're doing some extra work.

Focus on the formal API - send this request get this response.

djna
  • 54,992
  • 14
  • 74
  • 117
1

If there's some resource available in the API where the user search history is available, then it's not OK to do that, since your GET request has a visible side-effect. For instance, a client caching responses is under no obligation to know that any resource changed because he did a GET request to anything else. I think the only way to do this and stay compliant is to explicitly mark the side-effected resource as uncacheable.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

If that's kept only for internal usage, I guess it's fine to do it that way, but I still recommend against it.

Community
  • 1
  • 1
Pedro Werneck
  • 40,902
  • 7
  • 64
  • 85