The backend on that is Django. I might stick with what I know, or build SWAPI in Go. At the moment, we're still very early stage, so we can choose soon.
No worries and thanks for building it. You may want to put the email capture above so it's more clear as I'm probably not the only one to copy pasta the url in the examples and be confused for a moment until scrolling to the bottom.
I think it would be nice to also provide an endpoint that lists all the resources as an array of objects where the key is the id and the value is the name. Maybe something like this:
So RESTfully, I think this is normal. You should be able to call a resource and then be fed back all of those resources (usually paginated to say, 20 per request).
I guess the main reason is that data dumps are sometimes hard to sift through, can become inconsistent (if there are multiple copies) and because from my experience, if you provide an API for something, someone will use it. On the flip side: I've found that often people have always asked "why isn't there an API for that?"
And of course, you can easily get a data dump from this by just cURLing all the resources and storing them :)
Ahh, if only HTTP had defined a standard header for checking if the requested content has been modified, and sending a specific status code if that's the case...
Thank you for what you're doing, that's awesome!
I'd like to enlighten why choosing a license is important.
Many people can be picky about the license, because even though you may be full of good intentions, the data you provide is non-free as-is in that it can't be reused elsewhere. Having a license is the clean, boring way to tell everyone "do whatever you want with this data".
That's even a problem for Github, or more precisely Github users, because many people push some code without any explicit license, making this code hardly usable by default: it may be available but you don't know if you have the right to reuse it, even if the developer said "yeah, use this as you want". That's not enough. Just because the developer didn't take a few minutes to select and put a LICENSE file.
It is also important to think about it in the other direction: If you're going to take content from Wookieepedia, their license is CC-BY-SA (http://starwars.wikia.com/wiki/Wookieepedia:Copyrights), which means that you MUST say it comes (at least partially) from them (not that you wouldn't anyway) and that you MUST redistribute your content with a "similar" license. Even though you may think that everything is fine, there are some actions to do on this side.
Now, I'd understand that if only "amateurs" come and play with the data, we're all among good behaving adults and all is fine. But you may not be able to predict what will happen with how data is used, so unfortunately this step is important.
Personally I don't like restricting people, so I try to use CC0 as much as possible. Be aware that Creative Commons licenses may not be best suited for data (they were designed for work of art primarily), as can be seen by OSM's decision on the matter (http://www.osmfoundation.org/wiki/License/We_Are_Changing_Th...) so you may want to avoid them.
Note: I'm not even talking about money, which is an orthogonal problem.
If it's "All The Star Wars data [We]'ve Ever Wanted," then I want both. With tags telling me which data is 'original' and which changed in the '97 releases.
These are excellent. The little 'making of' documentary clip had me wondering what the fuss was about with the colour changes, but once I started watching I really appreciated it. Feels like popping the old VHS tapes in, but with modern resolution. Never knew how much it bothered me wondering if what I was watching was how I'd seen it originally (for the less obvious changes).
I usually do the same thing. Both the 32-bit issue (that issue being with JSON libraries, not the spec) but also: IDs are opaque tokens. If down the road it makes sense to use UUIDs or have a sharding hash or something else, you don't want clients tied to expecting an integer datatype.
That could happen but in a lot of strictly typed languages it would be non-obvious and special effort to do so.
There's absolutely no justification to send ints when you have any reasonable chance of needing to change it to a string later. Besides, IDs in a public API fundamentally are not numbers. You don't add them, subtract them, multiply them, shift them, inspect any property of them besides equality, or anything. They're opaque tokens used to identify things with the server.
56 comments
[ 4.0 ms ] story [ 50.0 ms ] threadMake that API great!
Whats the backend?
The backend on that is Django. I might stick with what I know, or build SWAPI in Go. At the moment, we're still very early stage, so we can choose soon.
Once things die down I'll push up an update. Getting a heavy bit of traffic right now.
GET /api/vehicle/t-65-x-wing
and
GET /api/planets/mustafar
will also work
and it will have better fuzzy matching.
It will have this style of lookup.
My initial guess would've been dynamic programming (levenstein distance), but if this is API-wide, did you make a suffix tree?
And of course, you can easily get a data dump from this by just cURLing all the resources and storing them :)
All resources will have a "date_updated" or similar attribute which you can check against.
As the data is already available freely elsewhere, I won't be charging or keeping the data, I'll provide it just like I do on http://pokeapi.co
Many people can be picky about the license, because even though you may be full of good intentions, the data you provide is non-free as-is in that it can't be reused elsewhere. Having a license is the clean, boring way to tell everyone "do whatever you want with this data".
That's even a problem for Github, or more precisely Github users, because many people push some code without any explicit license, making this code hardly usable by default: it may be available but you don't know if you have the right to reuse it, even if the developer said "yeah, use this as you want". That's not enough. Just because the developer didn't take a few minutes to select and put a LICENSE file.
It is also important to think about it in the other direction: If you're going to take content from Wookieepedia, their license is CC-BY-SA (http://starwars.wikia.com/wiki/Wookieepedia:Copyrights), which means that you MUST say it comes (at least partially) from them (not that you wouldn't anyway) and that you MUST redistribute your content with a "similar" license. Even though you may think that everything is fine, there are some actions to do on this side.
Now, I'd understand that if only "amateurs" come and play with the data, we're all among good behaving adults and all is fine. But you may not be able to predict what will happen with how data is used, so unfortunately this step is important.
Personally I don't like restricting people, so I try to use CC0 as much as possible. Be aware that Creative Commons licenses may not be best suited for data (they were designed for work of art primarily), as can be seen by OSM's decision on the matter (http://www.osmfoundation.org/wiki/License/We_Are_Changing_Th...) so you may want to avoid them.
Note: I'm not even talking about money, which is an orthogonal problem.
Couldn't resist... ;-)
We'll have episode VII details as and when it gets released.
As @simonsayscode points out, some folks aren't big fans of Episodes I, II, and III. Here's hoping for a fun VII.
And watching lots and lots of Star Wars.
I have the blurays, so I should be in for a fun experience whilst collecting the nitty gritty data.
http://originaltrilogy.com/forum/topic.cfm/Harmys-STAR-WARS-...
EDIT: And a donate button so I can reward you.
http://en.wikipedia.org/wiki/Han_shot_first
There's absolutely no justification to send ints when you have any reasonable chance of needing to change it to a string later. Besides, IDs in a public API fundamentally are not numbers. You don't add them, subtract them, multiply them, shift them, inspect any property of them besides equality, or anything. They're opaque tokens used to identify things with the server.
Would love more details and I can make a Virtual Copy of the whole thing.
Built it here https://vapi.ca.com