Now, I am by far no expert on developing API’s or doing API or key management, I am actually looking into services to allow me to do this and rate limiting, but I thought it would be nice to do a post on how I built and develop the xTravel API
If you ever decide to build you own API, get a structure on the go early, that is the biggest piece of advice I can give you right now. Originally, when I was building it as EdiTravel I was building under ‘/1.1/departures’ then ‘2.0/departures’ and so on and so forth. What that lead to, was a massive headache for one and also total confusion for two. Which API version was the newest one? Which API version was depreciated? Why did one crash and the other not?
I actually need to rebuild the structure for my xTravel API soon as some of the variable names make absolutely no sense. The thing is though, updating the version or variable names, won’t affect the production app and I can backport and change the variable names if I need to
Now, back to the point of this post, how did I build the xTravel API as it is today? Well, because I’m not very good with Docker or third-party libraries and prefer coding in a standard language, I used PHP and there is absolutely nothing wrong with doing that. It does the job I need it to do, so why should I need to spend ten hours trying to deploy it as a Docker container?
After moving away from the poor idea above where everything was basically re-written in each version and in combination with less crashes thanks to knowing how to use SwiftyHTTP I was able to use one API version for four different releases
| 404 Page Not Found |
The updates I’ve made the last three releases have been UI updates, using the existing API data and anything I add or update, doesn’t break or crash the app when it does not exist and I can back-peddle if need be
I use a combination of private HTTP headers in order to identify what API version the app so I can point a test version of the app to the alpha endpoint or I can push the production app on my phone to use the alpha endpoint thanks to some clever HTTP header checks and see if anything breaks, if nothing breaks, the new changes get merged into the main API version meaning I don’t have 20 odd versions, then the API is pushed to what I call ‘Staging’
Staging is my test/beta test endpoint, the API knows what build the latest app release is and if it detects it is higher than that, the user will get unknowingly pointed at the ‘Staging’ endpoint. Staging gives me the chance again thanks to HTTP header checks, to check there is no weird bugs using the updated API on the current production and that merging into master and not creating a new version is the right thing. If it’s wrong or broken, ‘Staging’ gets tweaked with the production app and iOS simulation running the latest alpha build to see if they can be made to work in sync. If they can, fantastic, if they just point blank wont’ then staging API gets pushed to a new version code, the production master gets pushed to the Alpha master so that the production master isn’t overwritten and affects old version when pushed to production and the testing starts on the ‘Staging’ with the Beta app
If I’m making any changes to the API, typically I’m adding things or tweaking things slightly, things that aren’t going to be noticeable in the production version.
So, if xTravel isn’t all that big an app, why go through all this effort? It’s a massive learning experience for one, working with recursion, alpha, beta and server testing and it is pretty sweet on the CV for two, and number three, it simply makes my life easier. I want to use my app the way I want to use my app with all the features I want from it, so I ensure it is the best it can be. Fourth and finally, I don’t want to be sharing an app that is half baked with a friend, family member or prospective employer and for it to crash or be unreliable.
It may not be a popular app now, but what happens if it does become big, how do I control it, how do I do version management, release management, bug tracking, error tracking? Don’t need to worry about any of that, as I’ve already built a process that I’ve become familiar with and can test and debug pretty easily.
A special mention must be made to this fantastic application which I was lucky enough to get free over Black Friday last year, it has made testing and working with API’s including third-party API’s so easy and simply. Having pre-defined variables you can switch between, for example, I have a bunch of Coordinates stored for different places that allow me to check different API providers. Change the dropdown to Edinburgh and run the request. Done. Change the dropdown to London and run the request. Done. No need to remember coordinates or codes or set special test headers. Simply, change the dropdown.
