The highly anticipated “Star Wars: the force awakens” new episode of the Star Wars franchise will be in display worldwide, and millions of fans will rush into theaters to watch it.
Paul Hallett created a Star Wars web API that lists movie characters, films, starships, vehicles, species and planets.
There are even contributed helper libraries available so that you can easily interact with the API from your favorite languages.
If you want to know Luke Skywalker’s height, the population of planet Tatooine, or the hyperdrive rating of a spaceship… look no further, all answers are here!
I’ve often used this API for my demos, and I was really curious to know more about it, and thought that could be fun to interview Paul to discover what’s behind!
Guillaume Laforge: Hi Paul, can you tell us a bit more about yourself?
Paul Hallett:
Hey Guillaume! I’m Paul, an API fanatic and Human. I live in London, UK where I work for a company called Lyst building API services. I also maintain the Star Wars and Pokémon API. I am also a committer and coach for DjangoGirls. Apart from being passionate about teaching programming and supporting open source, I also enjoy cycling and analogue photography.
Guillaume Laforge: I’m sure you’re a fan of Star Wars (who isn’t?) but how did you come up with the idea of creating an API dedicated to Star Wars?
Paul Hallett:
I had already built the Pokémon API a year before, in the space of a weekend, and it had proven very popular due in part to the data it provided, but also because it demonstrated good API practices and was very accessible. I had spent a lot of 2014 travelling to conferences and meeting people who wanted to keep building Web APIs that were very well designed. I thought I could do better than PokéAPI, and being a gigantic Star Wars fan (I have tickets for the midnight showing of The Force Awakens), I decided to build an API using data from Star Wars. I didn’t realise at the time that there wasn’t any structured data available already, I ended up having to watch each film, note down every character, planet and ship, and then gather the data from various sources online.
Guillaume Laforge: Can you tell us about the technical details of the API? What technical stack are you using, what infrastructure is it running on? What do you like about them?
Paul Hallett:
SWAPI is a Django application, using a popular plugin called Django REST Framework. The data sits in a postgresql database, with some memcache on top to reduce reads on the database. All of this sits on a tiny heroku application with cloudflare supporting as a CDN of sorts.
Guillaume Laforge: The Star Wars API is actually Open Source and can be found on Github. Is there a way for people to contribute to your project, are you looking for particular contributions?
Paul Hallett:
One thing that would be helpful soon would be data about the newest Star Wars film – The Force Awakens. Right now there is a lot of speculation and misinformation about who is in the film, so sourcing reliable data is tricky for one person. Making pull requests that adds to the fixture data would be amazing.
Guillaume Laforge: The API responses contain links to related resources. Have you considered using one of the few trendy Hypermedia approaches? (HAL, JSON-LD, SIREN, etc.) What do you think of those?
Paul Hallett:
I looked into supporting HAL and JSONAPI early on, but I didn’t want to do many complicated things at the time. I focussed on shipping something simple that worked. I guess I never got around to adding more to it!
HAL and other hypermedia-focussed approaches to API development are really interesting. They allow you to develop clients that are truly “dumb” and can just traverse through responses to discover actions, without any prior knowledge of what that resource can do. At Lyst, we’re building API services that use hypermedia to provide links to related resources, but we’ve found a good medium in a client that has some understanding of the API it is calling.
And of course, a standard is a standard, so if you opt to use one, stick to it! The biggest problem in the API world is people misinterpreting standards and building their own slightly different standard. (I am guilty of this too!).
Guillaume Laforge: Unless I missed it, I didn’t see any API definition covering the API, whether it be Swagger, RAML, or API Blueprint. That said, you can handily call the API directly from the website. What’s your take on API documentation and API definitions?
Paul Hallett:
The web browsable API is a key feature of Django REST Framework and makes it easy to explore the API, especially for beginners, who are the target audience.
I’m going to be a hypocrite and contradict my previous mention of standards. Whilst standards are good, I feel the API world has too many (and might be the reason people opt to roll their own), and it is sometimes hard to decide which is best. Swagger has a lot of traction, but I’ve found it has a high barrier to understanding. API Blueprint provides a great way to quickly build documentation, but it’s quite tied to Apiary’s definition, which you might not always want.
All of this led me to decide to not roll an API definition with the initial launch, and, as I’ve mentioned, I’ve just yet to have any open source contribution adding a definition to it yet.
Guillaume Laforge: The API already contains details about the new episode. How did you collect all that information? I suppose you expect to make an update to the API as we discover many more details with the release of the new movie? Are any other developments planned for the API beside the data update?
Paul Hallett:
I literally sat down and watched each film 
This was partially an excuse to watch the films again, but I had to pause it every 10 – 20 seconds to note down the appearance of a character, planet, starship, or creature. It was quite tedious.
After I did that, I used sites like wookiepedia.org to gather the data for all of those things I had noted down. It was only then that I defined the resources and their common attributes, and began building the data model.
Apart from data updates, I do not plan to do a whole lot of work to it myself. I need to fix the counter, which is broken! I am more than happy to accept contributions of any kind, if they make sense.
Guillaume Laforge: Which movie has been your favorite so far, and why? Do you anticipate the new episode will be the your new preferred one?
Paul Hallett:
I absolutely love The Empire Strikes Back. It’s dark, it ends on a sad yet hopeful note. It contains the biggest plot twist in cinema history. Who’d love any other film?
I am very excited about the new film, I feel like JJ has taken what made the original trilogy so heartwarming and exciting, and has adapted it well for a modern audience. I anticipate that it’ll be a good thing, and I hope it helps to shape film in the next decade.
Guillaume Laforge: Who’s your favourite character in Star Wars?
Paul Hallett:
Without a doubt, Han Solo. Who doesn’t love a scoundrel?
Guillaume Laforge: Have you already booked your tickets for the new episode?
Paul Hallett:
Yep, midnight showing tickets booked!
Guillaume Laforge: Paul, thanks a lot for your time for this interview! Enjoy the new movie, I’ll be thinking of the API when watching it! Any parting thoughts you want to share with us?
Paul Hallett:
The best approach to building great APIs is to design it first. Engineers always jump straight into the code, and this produces bad APIs (Web or not). Take time to think about the resources you have, what you want the functionality to be, and how it can map to HTTP. Try and stick to HTTP wherever possible. Bend the rules when it’s the right thing to do, not because it’s easier. I wrote all my thoughts on API design recently at bit.ly/api-best-practices and I’d love to try and share some of my experiences with the wider world.
If anyone has questions, they can find me at twitter.com/phalt_
Thanks for having me Guillaume, and May The Force Be With You!