> The point of using different HTTP verbs - chaching. Don't do > GET /deleteItem?itemId=456 Yes and no. Use DELETE for delete basically for that reason, but

> The point of using different HTTP verbs - chaching. Don't do > GET /deleteItem?itemId=456 Yes and no. Use DELETE for delete basically for that reason, but the statement that there are different verbs for caching is wrong. That's what a variety of Headers are there for. The fact that GET is in many cases cached simply is that a GET isn't there for state changes, so it doesn't matter whether it reaches the server (headers are there to tell whether it should). That's for how things are meant to be, but I agree that it often isn't like that. Properties of HTTP were (ab)used for other things. I think that's a mixture of not understanding HTTP (in other words, not having read RFCs) and of course practical reasons. We can see that a lot in the web in general. A lot of things get used in different, often completely wrong (as in standards breaking ways) and so things are not really coherent. That includes HTTP, HTML, CSS, ... and that's why new versions of these standards and up having a rather strong break. Caching is actually a great example if you look at HTTP/1 vs HTTP/2. But you may also be look at tags like <i> or <b> in HTML. They started out for styling, then they were discouraged and now they have a more semantic reasoning (see HTML 5's definition). Doesn't mean that how it is used a lot is exactly bad. It actually just shows that the original ideas, the REST dogmas, etc. maybe don't fit and people use the best from RPC and REST. HTTP is used really universally, which also explains why there are things like WebSockets which barely fit with the original ideas and concepts of what HTTP is. On the other hand it worked extremely well, when you look at its popularity.