Should PUT and DELETE be used in forms?

Question

Assuming my web application has full support of PUT and DELETE on the server side, should I make use of them?

Basically my question is how many browsers support this:

<form method="PUT">

or

<form method="DELETE">

Is there any benefits to using these two HTTP Methods other than being REST-compliant? (assuming the replacement for these two methods is the commonly used POST)

Connaught

Answer 1

Your question involves two closely related but separate standards, HTTP and HTML. The PUT and DELETE methods are part of HTTP. In HTTP they have obvious use in RESTful interfaces, and other services which build on HTTP such as Webdav.

HTML up to version 4 only defines the use of POST and GET for forms. HTML5 at this time appears as though it may support the further methods. [note, support is not included in the current w3 draft]

Any current browser support (I'm not directly aware of any) will be very limited and only really useful as an experiment at the bleeding edge.

Tay

The current HTML5 draft does not support PUT or DELETE in forms. The relevant section is currently in at "last call for comments", so it's possible they'll be implemented but unfortunately it doesn't look like it. I think it was in there at one point and then removed. – Flight

Regarding browser support, mozilla have this ticket of interest for FF4, which indicates they did support it but have now removed it - bugzilla.mozilla.org/show_bug.cgi?id=600813. – Tay

@andrew Indeed, it was part of the draft for several years, but was removed late last year. My intention wasn't to suggest that it will be part of the standard, only that it may be. – Tay

I'm quite disappointed for the removal of these methods, as they make much sense. Does anyone have a link for the reason behind this decision?. – Alphaalphabet

@Triztian w3.org/Bugs/Public/show_bug.cgi?id=10671 and for the full story: programmers.stackexchange.com/a/211790/26123 – Lilialiliaceous

Answer 2

GET, POST, PUT and DELETE (there are others) are a part of the HTTP standard, but you are limited to GET and POST in HTML forms at this time.

As Andrew mentioned, you can use PUT and DELETE in AJAX requests; however, this only works in some browsers (see http://api.jquery.com/jQuery.ajax/).

Suzisuzie

Answer 3

No, GET & POST are the only valid HTTP method values for the method attribute. See the HTML spec for more information.

I believe you can use them in AJAX requests, though.

Flight

Link is broken. – Wieche

@code_dredd, someone opened it with DELETE instead of GET – Alfaro

@Alfaro Not sure if you're suggesting that I did that, but clicking the link from the browser doesn't do that. – Wieche

Answer 4

As of January 2024, latest HTML specs and drafts still don't have support for methods other than GET and POST by default. If you don't use a method middleware, you are stuck with these two options. (method attribute can also have 'dialog' as a value, but it is irrelevant since it is not directly related to HTTP methods.)

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fs-method

Maricela

Answer 5

It's not really possible to send a DELETE request using <form />, but you can send one to the one API endpoint and redirect the user to another page. This will simulate the desired behaviour. The code with jQuery is provided.

$(".control-action").on("click", () => {
  alert("Click");

  $.ajax({
    // call a DELETE endpoint of API
    url: "/api/items/5",
    method: "DELETE",
    headers: {
      "X-Api-Key": "363463822036d927c733d5607af109e2"
    },
    success : function () {
      // redirect to another page
      // window.location.href = "/items";
    }
  });
});

.link {
  text-decoration: underline;
  cursor: pointer;
  color: blue;
}

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/2.0.3/jquery.min.js"></script>

<span class="link control-action">Call action</span>

Moradabad

Answer 6

Others have explained it well but you can visit this answer on Github for more explanation

Probably not as that would complicate the processing model for <form> quite significantly. In particular, the same origin policy exceptions <form> has today do not allow for these methods. Either we have to forbid them in cross-origin requests or require CORS somehow. Both of those restrictions would be a first for navigations and rather risky.

Acierate