Schema types standardization about swapi HOT 8 OPEN

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.

from swapi.

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?

from swapi.

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.

from swapi.

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 :)

from swapi.

@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:

from swapi.

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

from swapi.

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

from swapi.

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. :)

from swapi.