On Wed, 6 May 2020 at 17:49, Adam Johnson <m...@adamj.eu> wrote: > +1 request.data >> >> We shouldn’t be POSTists, there is also PUT and PATCH. >> > > Would just like to point out - that's not the proposal. The proposal is to > rename the existing request.POST to request.form_data, which is based on > parsing application/x-www-form-urlencoded data from request.body. Browsers > only send such data in the body on POST. >
That is a fair point, but also AJAX/JS can do those other things, including POSTing JSON, as mentioned above. Let’s use something more generic then `form_data`, more focused on the actual mechanics of data transfer (data in body vs data in query params) rather than focused on the intent (form, query, navigation, API…) Because, also as mentioned above, users will have to understand these things anyway. Something like `request.data` can hold decoded fom data just like `request.POST` does now. In the future, we can include decoded JSON in there too, so we don't have to `json.loads(request.body)` any more. Also XML anyone much? :) Basically what DRF does with parsers. This is, of course, way outside the scope here, but perhaps it is worth keeping the names in line with the long term goals (if something like decoding JSON and other formats, DRF-style, is a goal, IMHO it shold be). request.data is also somewhat wague, but at least not misleadng. Maybe request.body_params, request.decoded_body, request.body_data, request.content? An argument for `request.data` is that is will end up in `form.data` in the usual use case, so a nice symmerty there. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAM2o%3DwMC3yAP-wN5aZg7Xwqsm-ib4cDg%2B5%3DhPMV5h4FaYVZ4DA%40mail.gmail.com.
