Which is in contradiction with the HTTP spec. Because who lets a user just add and remove resources without using a process or handler to handle the user input?
I would not use such a framework, because it did not understand HTTP and HTML specs in the first place.
> Because who lets a user just add and remove resources without using a process or handler to handle the user input?
I'm not sure what you're talking about:
1) It's user input and the user can craft a DELETE request just as well as add a _method=DELETE to the form body.
2) Most frameworks use the _method parameter as the http method, meaning when routing or when the application asks for the method so as to take specific actions. No general framework just deletes or creates stuff for you (unless you specifically set it up to, and even then you can normally add an authorization check hook).
I may have misunderstood the point you tried to make. Let me try again to make mine.
The reason HTML uses an enumeration ("get" and "post") and maps those to HTTP methods ("GET" and "POST") is that they have special meaning for user interaction. With "get" a form becomes an URI builder. With "post" the user can send data to the server. You can call it a coincidence that the values of the enumeration match the HTTP methods. The reason a "post" form is mapped to a HTTP POST is that a server should always process user inputs - even if the behavior of your application results in deleting a resource.
So yes, okay, the frameworks behave correctly, because they process user inputs. My point was to question the intent or reason behind a "_method" parameter of those frameworks. If such a framework invented the parameter because it felt limited by the HTML specification, it did not understand the specification. If it is about automating resource management, then I'm fine with that.
BTW. which frameworks do you mean? I know none (never saw that in Spring Web or WS RS implementations like Jersey).
Where we disagree is about the meaning of method in a form tag. Since it's called method and since the options are a subset of HTTPs methods, it seems natural to assume that they are related. Missing http methods does seem limiting with regards to a restful interface.
