We have many clients which, upon start up, request a specific resource on the server using an HTTP API (not RESTful). This resource is - currently, identical for all clients.
Naturally, since the client is requesting data from the server via HTTP, a
GET is used.
Incidentally, we wish to log the access of this resource as it is vital to the startup phase of each client and represents potentially valuable support information.
The HTTP spec, however, states in no uncertain terms that a
should not have any side effects (section 9.1.1). I can think of several possible solutions to this issue:
Have the clients perform a
POST, as it is not an idempotent action.
Do not heed the spec (after all, it is a
should not) and update the last access time for the given client when the
Create post-method hooks which update the last access time for the given client.
1 is definitely not an option in our case, as our clients are not easily modified and even then do not have compulsory updates.
2 is likely the most straightforward option which guarantees that the business requirements are met.
3 is a possibility, yet necessitates (as far as I can see) an asynchronous update which then may fail as it is no longer part of the original request. Additionally, it necessitates the strong coupling of technical code with business logic, which is something we try to avoid.
As far as I can see, option 2 is the only course of action we could take as it fulfills our requirements while not completely stomping on the spec or ruining our code.
Are there other ways which would potentially be better? Is there perhaps another common way of logging access times to secured resources similar to audit logs via HTTP?
GETnaturally maps to a query. Could you elaborate how auditing may be combined with this approach? Should it perhaps be decoupled from the business logic, in this case?