PUT specifies the resource to be update, whilst POST does not do so. This means that you must (according to RFC 2616) use POST if you want to create a new resource and PUT if you want to change an existing resource or create one that you know "how to name". This disctinction is sometimes necessary, or at least useful (ex: idempotence of PUT).
I don't understand how any even half-competent developer would be unable to understand this difference and act accordingly.
What if you want to update a value, but you want to store the number of times it was updated to be returned in the JSON (not idempotent, but not an unreasonable thing to want)? Would you still use PUT?
My point is not that the ascribed meaning of POST and PUT is bad, I think the concepts behind both these functions are great, but what if you want to make a different or more complicated function? It makes sense to me to invent your own rather than be limited to what HTTP gives you.
I suppose you could expose the counter as a separate resource. It depends how important that counter is. If it's somewhat incidental, you could use PUT. If it's key to your system, use POST for updating the counted resource, because it's not idempotent.
You examine the situation and determine what makes the most sense. Do you want the client to repeat the request if it's not sure whether it succeeded or not? If so, use PUT; otherwise use POST.
PUT specifies the resource to be update, whilst POST does not do so. This means that you must (according to RFC 2616) use POST if you want to create a new resource and PUT if you want to change an existing resource or create one that you know "how to name". This disctinction is sometimes necessary, or at least useful (ex: idempotence of PUT).
I don't understand how any even half-competent developer would be unable to understand this difference and act accordingly.