request.data in DRF vs request.body in Django
In rest_framework.request.Request

request.body is bytes, which is always available, thus there is no limit in usage
request.data is a "property" method and can raise an exception,
but it gives you parsed data, which are more convenient


However, the world is not perfect and here is a case when request.body win
Consider this example:
If client send:
  content-type: text/plain
and your REST's endpoint doesn't accept text/plain
your server will return 415 Unsupported Media Type
if you access request.data
But what if you know that json.loads(request.body) is correct json.
So you want to use that and only request.body allow that.
FYI: A described example is a message of AWS SNS notification sent by AWS to HTTP endpoint. AWS SNS works as a client here and of course, this case is a bug in their SNS.

Another example of benefits from request.body is a case when you have own custom parsing and you use own MIME format.
Django REST framework introduces a Request object that extends the regular HttpRequest, this new object type has request.data to access JSON data for 'POST', 'PUT' and 'PATCH' requests. 
However, I can get the same data by accessing request.body parameter which was part of original Django HttpRequest type object. 
One difference which I see is that request.data can be accessed only one time. This restriction doesnt apply to request.body. 
My question is what are the differences between the two. What is preferred and what is the reason DRF provides an alternative way of doing same thing when There should be one-- and preferably only one --obvious way to do it.
UPDATE: Limiting the usecase where body is always of type JSON. Never XML/ image or conventional form data. What are pros/cons of each?