Schema types standardization

[AliSoftware]

Why always use Strings for all types, where some properties would make more sense if they were integers or doubles (especially people.mass & people.height could be doubles, and even people.birth_year could be a signed integer (which could be null if unknown).

That would make the parsing much more easier, instead of having to parse each string client-side.

[phalt]

Purely down to how I implemented it originally. A migration to the new format might mess up people's applications now. However, if you're familiar with Django and want to make the suggest migrations - open a PR.

[AliSoftware]

Unfortunately I don't know a thing about Django.

Note: given that the API and schema will undoubtedly change as you will implement then other issues — like changing the pilots to be a dictionary of {name,href} instead of directly an url, etc — won't you create an /api/v2/ endpoint anyway?

[phalt]

I want to avoid hard coding versions in the URI. The URI isn't really used for that purpose. I was considering an http header to set the version and determine the response schema.

But yes - a lot of people want me to changes things (no one is actually making any contributions yet though) and those changes will probably all be rolled into a version 2 at some point. However - I am not accepting every single request otherwise it'll be a mess.

[AliSoftware]

I feel you. I'd gladly help and do a PR but I don't know a thing neither in python nor Django (My stuff is ObjC, Ruby and Swift) :-/

Good luck and thx for this fun app :)

[phalt]

@AliSoftware It's tough when you put something in the public domain and then things start to use it - suddenly you have to support legacy. It's easier for software because versioning is easier, but with Apis it can be really tricky D:

[phalt]

Just remembered: there is also the issue that some values have n/a where integers or decimals might be

[AliSoftware]

You could use null when values are n/a ;-)

[quellish]

http header to set the version and determine the response schema.

Using the Link: header as described in section 8.2 of the JSON schema specification would be a very welcome change and unlikely to break existing clients. :)