DPCS-team / DPCS

Data Powered Crash Solver
7 stars 17 forks source link

Django server compability with http://docs.dpcs.apiary.io/ #80

Closed patrikos94 closed 8 years ago

patrikos94 commented 8 years ago

Please, take a look at _____README____ file.

bdfhjk commented 8 years ago

@patrikos94 How to check the crash report adding via curl? Could you provide me the command you have done it with?

bdfhjk commented 8 years ago

I've set up your server at bardonski.pl:8123

patrikos94 commented 8 years ago

I've written some examples of the curl usage of the operations supported by the server. I hope you find it useful. examples_curl.txt

bdfhjk commented 8 years ago

You have made a mistake with the JSON format, that's causing a client application to crash.

http://jsonlint.com/

check the result of: import json json.loads('{"a":None}')

patrikos94 commented 8 years ago

If you fixed the issue then you don't have to read this.

In the apiary there was no notion of what happens if there is no value assigned to the key. Currently, there is no clustering and classifying code executed on the server side, so something had to be assigned for a crash_group_id field, or solution_id, etc. fields. In this case None value(which corresponds to null in some way) was assigned. Ultimately, with the classifying and clusterizing module no such value should be returned.

Anyway, json.loads works with string like json objects. If we pass in None value it wouldn't be able to decode it, since it's not a string or an int or primitive data type. To fix the issue you could write json.loads(json.dumps({"a":None})). This will first encode the json object, and then decode the stringified version of the json object.

You could also encode the json on the server side, by changing lines that match the pattern:

return Response(json_resp, ...) to return Response(json.dumps(json_resp), ...).

In general it is a good practice to do it on the server side and send the encoded json from the server, however, in the current implementation, doing that would cause side effects to the Django Rest Framework since I couldn't find a way for django rest framework to display string-like json correctly. The string would still be a valid json but it wouldn't have indentation, newlines with each fields, etc. when displayed.

We could also change the code to fully use serializer class, but it would take some time, since I haven't tested it against python urlib2(only curl and GUI).

And so, since time is of the essence, in case there is not much json.loads on the client side you could consider replacing each one of them in a wrapper function like:

def get_json(response_json): return json.loads(json.dumps(response_json))

This way, if you wanted to switch to production and keep with stringified json objects you would have to switch just one line. json.loads(json.dumps(response_json)) -> json.loads(response_json)