Support 1.8's UUIDField

[tomchristie]

As per comment here: #2426 (comment)

Current str field would result in...

File "/Users/tomjaster/DevFolder/master/airyengine/airy/lib/rest_framework/utils/encoders.py", line 60, in default
    return super(JSONEncoder, self).default(obj)
File "/usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/encoder.py", line 184, in default
    raise TypeError(repr(o) + " is not JSON serializable")
    TypeError: UUID('335680b8-0f20-4e25-a0e2-3caa052a3e83') is not JSON serializable

We should validate UUID values, and handle str() of them in both the encoder, and in the serializer field.

[toranb]

@tomchristie First up - I cannot tell you how long this project has been putting food on my table. But not "just" supporting my family => this project is an absolute JOY to work on /read / contribute back to. From the bottom of my heart -thank you for all the time/blood/sweat/tears you've put into this amazing OSS project!

Now the question I had about this issue/and the related PR ....looking over the tests I don't see a high level /acceptance like test that shows if DRF 3.x supports the ability to post with a uuid (ie- from a client app) and have it persist in the django orm w/out issue. Is this feature truly supported in DRF? If so do you have an example/know of a test or project I could look over to play with it?

[aaronlelevier]

Here is the SO answer to accept a id from the client. The issue was that id is read_only=True by default.

http://stackoverflow.com/a/31688834/1913888

[tomchristie]

Seconding the s/o answer. Declare the field explicitly to override the default one that'll otherwise be created for you.

class PersonCreateSerializer(serializers.ModelSerializer):
    id = serializers.UUIDField()

    class Meta:
        model = Person
        fields = ('id', 'username', 'email', 'password')

And thank you so much @toranb - wonderful start to the working day to get a comment like that.

✨ 😎 ✨

It's a pleasure to work on.