Auto convert data into json if Content-type is set to 'application/json'

```
>>> r = requests.get('https://api.github.com/user', auth=('user', 'pass'))
>>> r.status_code
200
>>> r.headers['content-type']
'application/json; charset=utf8'
>>> r.encoding
'utf-8'
>>> r.text
u'{"type":"User"...'
>>> r.json()
{u'private_gists': 419, u'total_private_repos': 77, ...}
```

If the response is `json`, requests auto converts to `dict`.

```
import requests

data = {'name': 'kracekumar', 'lang': ['python', 'go']}
headers = {'Content-type': 'application/json'}

r = requests.post("http://api.someserver.com/v1/profile/update", headers=headers, data=data)

```

Here I have set `content-type` to `json`, but forgot to encode the data to `json` (made this mistake multiple times), server will complain. 

I think auto converting `data` to `json` will bring consistency to requests since `json` is converted to `dict` in response.
### Implementation

If `content-type` is set to `application/json` and data is `dict`, do `json.dumps(data)`.


Hey, thanks for thi @kracekumar!

I don't think this is a good idea, however. The key reason is that auto-converting outgoing data is upsettingly magic. As much as possible, what you put in one parameter to the request function (e.g. `headers`) should not affect what happens to something that came in on another parameter (e.g. `data`, or `auth`).

It's also not quite the same as what we do on `Response`s. For a `Response`, we don't automatically convert to JSON unless explicitly asked to by the user: that is, they have to actually call `Response.json()`. That fits the Zen of Python ("Explicit is better than implicit"). For that reason as well, I'd rather that we stick to the current behaviour.

Let's leave this open to see if @sigmavirus24 agrees.


Oh, Now I got the point why `response.json` was made `response.json()` in 1.0.0. 


This has been proposed countless times before and every time it has been shot down. We analyze your request to make sure that it appears as correct as we can possibly ensure without restricting what you can actually send.

As @Lukasa said, headers have currently no effect on any other parameter we use and they shouldn't have any effect here. `data`+`files` has an effect because it's the simplest API to making a `multipart/form-data` request especially since sending a file is safest when using that multipart type. Beyond the fact that this is a bad design for an API (it is entirely unintuitive), we would then have people insisting that because we accepted this then we should also accept other `Content-Type` headers and parse the other parameters based upon that. For example, someone might insist that we accept a header like `multipart/form-data; boundary=xyz` and dictionaries for `data` and `files` and then parse out the boundary and create a multipart/form-data` request. That is insanity.

Someone else might want us to turn his dictionaries into XML for him... 

You can see exactly where this rabbit hole goes, just like https://github.com/kennethreitz/requests/pull/1779 led to https://github.com/kennethreitz/requests/pull/1785

Finally, you seem to already understand it, but let me stress:

``` python
import requests

r = requests.get('https://www.google.com')
r.json()
```

Will raise an exception as well it should. In both your example, and this one though, calling `r.content` **or** `r.text` will get you the body of the response.

I'm :-1: \* 10 on this (regardless of how convenient it would make developing things like [github3.py](https://github.com/sigmavirus24/github3.py)).


Sorry, I didn't think people may request similar kind of features for other content-types. Only reason to propose this was `json` is so commonly used.  

I am ok to close the issue. 


Alright then, let's close this. Thanks for the suggestion @kracekumar and please keep them coming! We always say 'no' to more things than we say 'yes' to, but we can't say 'yes' to things people never ask us to do. You're doing good work! Keep it up.

:cake: