Accept Answer URL should be idempotent and accept PUT or POST requests only

Answers currently users a single URL to both accept and un-accept answers:

${base_url}/accept_answer/${answer_id}.

If this URL is requested and the answer in question is currently un-accepted, its state will be changed to accepted. If the answer in question is already accepted, it will be un-accepted.

This is a bad API design, as it means that repeated requests to this URL will cause the answer to toggle between the two states endlessly. Since accepting an answer also causes an email notification to be sent, this makes Answers vulnerable to a storm of email notifications being generated.

Idempotent Web APIs are a good design practice. Additionally, having a GET request that is not idempotent actually breaks the contract of the HTTP protocol[1].

9.1.2 Idempotent Methods

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

Additionally, GET requests should not be used to modify the state of entities on the server. The fix for this bug should probably be in two parts:

1. The accept_answer end-point should be broken up into two separate accept_answer and unaccept_answer end-points.
2. The end-points should be modified to accept only PUT requests, instead of GET requests.

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