Most people use GET and POST for all of their requisitions, are there any major problems that should be considered a real reason to respect the correct semanthics?
What are the disadvantages on the lack of using "HEAD","PUT","DELETE","TRACE",etc.?
The semantics of every HTTP verb is known by clients (like browsers) and intermediate equipments as well. They treat requests accordingly (in terms of logging, caching, replaying, etc...)
Some examples:
GET/HEAD request is considered "safe" and can be replayed a number of times without breaking anything. On the other hand, a POST request is not considered "safe" because it implies a remote state modification. That's why when you navigate by posting a form, and you click the "back" button of your browser, your browser asks if you want to POST the form againGET request should be used to retrieve a remote resource. That's why the resource can be cached in intermediate HTTP-aware equipments in order to reduce the number of requests on the backend systems. The response of a GET request is considered cacheable (it's implemented in Service Workers, web servers, HTTP proxies, etc...).GET request in place of a POST, that means you're sending the payload in the URL and that means potential sensitive data logged by the backend, and all of the intermediate equipments (an URL is considered as a loggable non sensitive information)PUT, PATCH, DELETE, there is no major concern about using a POST instead of one of these, they're here to help you build self-documented RESTful APIs, define fine-grained authorizations on the endpoints and are pretty similar to POST when we forget the semantics (non cacheable, non replayable, hold the data in the body, if concerned)