Fix json body request apis

[dimon222]

Fix #75

[kevin-bates]

I applied this change to my env and it works great. Nice catch!

When I went to apply the change, I noticed a number of other requests in which dictionary data was conveyed in data= rather than json=. I don't really use any others, but wondering if those should be changed as well?

[dimon222]

Its highly possible but I don't have necessary configured cluster to test them sadly.

[kevin-bates]

I think we should change them all.

Looking at the requests package, we'll get the appropriate encoding if json= is used. Whereas it looks like we'll get form encoding using data=. So, even though the header contains Content-Type: application/json, the actual encoding of the body doesn't match the header and more sensitive libraries get heartburn.

In my attached test code, I was passing in the actual json when submitting the application. This was associated with a data= in our package. I believe that because this was properly encoded, submission works. However, if I pass in the dictionary (prior to its conversion to json), submission fails with a bad request exception.

Response finished with status: 400. Details: {"RemoteException":{"exception":"BadRequestException","message":"java.lang.Exception: Could not parse application id ","javaClassName":"org.apache.hadoop.yarn.webapp.BadRequestException"}}

Once I change cluster_submit_application() to also use json= and pass the dictionary data, then submission also works.

Since we document the data parameter as "dict data" and given that all methods that hardcode their data payloads (like kill, change-queue, change-priority, etc.) are actually passing dictionaries, then I believe the right thing is to change all data= to json=.

[dimon222]

@kevin-bates alright, pushed the commit and renamed the PR.

[kevin-bates]

Thanks Dmitry! Given the evidence of the methods that are used, I think this is the right approach.