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

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ x ] Feature request
[ x ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see

Current behavior

The HttpClient.delete() does not accept a body parameter.

Expected behavior

The HttpClient.delete() needs to accept a body or clear guidance on why it has this limitation and how to get around it. It was possible with the original Http.delete() via the RequestOptionsArgs

What is the motivation / use case for changing the behavior?

I work with APIs that have always handled the body of DELETE requests and this is an unexpected change in REST api interaction.


Angular version: 4.3.2

- [ x ] Chrome (desktop) version 61.0.3163.79
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX

29 Answers

✔️Accepted Answer

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: { ... } });

Other Answers:

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


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.

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.

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.


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.

Guys, DELETE does not have a body by design - It's a standard.

More Issues: