angular: HttpClient.delete() cannot handle a body in its request

It would be great to have body param in .delete().

We just migrated our project to HttpClient and for now we used:

http.request('delete', url, { body: { ... } });

Guys, DELETE does not have a body by design - https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/DELETE. It’s a standard.

I did. I also looked up the spec, which is actually linked a little further down in that page:

RFC 7231, section 4.3.5: DELETE

specifically

A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.

There seems to be some debate as to what this means exactly, but a conclusion I’ve seen (and agree with), is:

• The DELETE method does not need to support it.
• Likewise, there is no prohibition on supporting it.
• Clients should not assume it is allowed on any given server.
• If you support it, there are no particular rules about how.

In other words: It’s up to the API.

Like I said, this is a convenience thing, and hardly critical. But I don’t see any HTTP-specification-based reason not to allow it.

Can you please add this functionality in next version. It would be a great. Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/DELETE “Request has body | May”

Using Angular Version: 5.1.3. I am also facing same problem.

Angular is a medium, not the API itself. If the API doesn’t forbid it, Angular shouldn’t make the decision for the dev. If someone is developing full stack, they have sufficient control over the REST handling to properly handle DELETES with payload.

Look at the table on that link, it says in the 1st row:

Request has body | No

It’s worth pointing out that MDN has corrected their documentation to reflect that the DELETE method “May” have a body, even if some sever implementations out there don’t like it 😃

There are some good reasons to support this feature in the client API, especially since it was already working and is straight forward to re-enable…

• First, upgrade paths become unnecessarily more difficult for folks, with no real upside. Even if it’s supported in some other more clunky mechanic, first class support in the API is obviously better and less of a breaking change from what is expected.

• Second, the RFC supports this functionality and servers can optionally decide to implement it / support it / be mad at it. No worries and no skin off our backs. Having some minimal / deficient / partial support server implementations out there shouldn’t drive support for the functionality on the client side when there’s clearly usage and servers that do support this feature.

EXAMPLE

An example of how this feature can be very useful and which would be hard to accomplish outside of resorting to the good ole use PUT/POST instead of DELETE as a workaround:

• Extra data that is passed along in a DELETE can be used to validate that the resource the client is attempting to delete has a particular state (e.g. passing in the resource we just retrieved from a GET or something like a timestamp, which may be large / unwieldy / non-loggable in a RESTful API URL)
• If the state sent with the DELETE request no longer matches the server state, then bail with an error. Changes have been made to the resource the client is attempting to delete, which can be very bad and lead to unexpected results if the operation continues. Given the destructive nature of these types of operations, ensuring the client is deleting exactly what they are intending to is important.

There are few other options for items like this that still feel RESTful and non-dirty. +1 for pulling this back up and re-enabling first class support for a feature that many folks take advantage of.

yes this is working in angular 7 project with http delete

http.request(‘delete’, url, { body: { … } });

Thanks Its working.

Comon guys, so long and sensible discussion. Topic open for more than a year and another dev like me facing the same problem. Googling, reading and posting instead of coding - please decide on that one.

Bumping this ancient issue as workarounds can only take you so far. Had to use the workaround but that kinda feels shady at the same time. 😦

Also, you can use HttpClient.request with method: 'delete'.

Sorry guys but you can’t fight gravity… Again HTTP is a protocol internationally used. The World Wide Web Consortium (W3C) is the global organization that is responsible for maintaining it not MDN (Mozzila Developer Network which might be part of W3C, but MDN alone has no say in the matter): https://www.w3.org/Protocols/

Thus I reiterate what has bee said before (with corected RFC):

Conform RFC 8231 Sec 4.3.5: https://tools.ietf.org/html/rfc7231#section-4.3.5

“A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request”

Therefore you could send the body with your DELETE request, but do you want to risk the server rejecting your request?

Suppose your backend service supports a body with a delete request (such as Spring MVC wich does so as a side effect of inheritence, thus a defect in Spring), if Angular were to implement said feature it would be GOLD PLATING as is not part of the HTTP protocol.

Proceed on your own risk!

+1 would be very useful to be able to send payload with DELETE request, as a lot of people write their own servers Angular app communicates with

Look at the table on that link, it says in the 1st row:

Request has body | No

This now says “May”

PR #41723 from @gopal-jayaraman landed s we can close this issue 👍

@sumansanohub like this:

this.http.request('delete', url, { headers, body: remarks });

This is a bad thread

Because it’s optional on RFC means it should be allowable on Client side

http.request(‘delete’

workaround is bad because is Angular going to make http.request(‘delete’) also forbid Delete Body, randomly?

Some basic rpc/old server apis don’t have ID’s in the URI for example, so those must be passed in the body in my case.

I’m still going to use the work-around for now, and just hold thumbs.

Hey guys I had the same problem and I solved the same way you guys recommended, thanks, by the way!

this.httpClient.request('delete', `${this.API_URL}/product/${product._id}`, {body: product})

It would be great to have body param in .delete().

We just migrated our project to HttpClient and for now we used:

http.request('delete', url, { body: { ... } });

it works like a shine thanks @rgalkaS

+1 need to call multiplie DELETE endpoint with a payload in the body

Ran into this, and I guess that the angular dev team decided to disallow it on http.delete(...) to raise some awareness to the fact that it might not be supported on some servers (aka prevent problems) and they left the “workaround” of using it with the generic version: http.request('delete', ...

IMO it’s a difficult decision either way as young blood devs either lose time searching a bug, of might do so searching why the server is ignoring the body 😛

Anyway it seems that Angular let us put a body in a DELETE request, and since 4.3 version it didn’t. So, @alvipeo , if it’s a standard, Angular was wrong before new version?

I also just ran into this problem when I tried to migrate from the old HttpModule to the new HttpClientModule. 😦