What a world cup! I do feel bad for 50% of the MuleSoft team though (given that we’ve got a big office in Buenos Aires). It’s exciting though, because this was a very exhilarating competition that truly reached a fever pitch here in the US where “football” is traditionally a game with pads, helmets, and ball that doesn’t really roll.
What was really interesting was how this was truly a, “World Cup powered by APIs.” World Cup organizer FIFA has stated that more than a billion fans worldwide accessed information about the tournament through its digital platforms. I personally watched many games on my mobile phone, my tablet, and on my laptop. In fact, I distinctly recall being in the middle of a long line and putting on the Brazil – Columbia game that was streaming over a 3G network in San Diego.
“This has been the first truly mobile and social World Cup”
– FIFA president Sepp Blatter.
What actually went behind the scenes of this whole experience was an API infrastructure that allowed media entities to expose their digital assets and stream live media over end user devices. There were countless mobile apps that were consuming APIs and even more digital assets behind those APIs.
Here’s the tough news: having a strategy and a program that allows you to build such infrastructure is incredibly complex.
It could have easily been a 3 month effort, to build up all this infrastructure where you need to design the API, implement it, scaffold it to the backends, secure the API and then apply management practices like rate limiting and throttling. Moreover, building the infrastructure to monitor application usage, and API analytics, and the community evangelism practices like developer self service sign-up and on-boarding documentation is something that shouldn’t be overlooked.
Start by designing your API
So once you’ve decided to go after a mobile app strategy, where do you actually start?
First of all, you need to expose the data and digital assets for the mobile app developers – and you’d do that through an API. In essence, you need to “whiteboard” what the API can look like, get feedback on whether it makes sense to the developers, and then after some validation you can start to actually implement the API. This is analogous to the principle of doing UX testing for an application before you start going down a path of heavy development. In the same vein, APX is critical to the API – more so today than ever. The key point here is to differentiate between the “interface” and the “implementation” of the API. What does an interface of an API look like, and how do you go about creating one?
Here is an example of an interface of a World Cup API I have quickly drafted and “whiteboarded” the API using the API designer. The API ended up looking like this:
All I did was create a functional model of what my API should look like, and I know this because I visualize what I want the apps to show (and what data I have and how it would make sense to those apps) and then create those functional groupings in terms of “API resources” (countries, players). Next, you need to decide whether you want applications to be able to modify the data, or should they be read-only. Based on that, you’ll specify methods on each of those resources. As the application collects data, it might want to digest it in a specific way and so you might want to introduce additional parameters to control for that. For example, if an application wants to sort through the list of countries in alphabetical order, you can define a request parameter with values of “ascending” or “descending”. And as simple as that, I was able to whiteboard an API, and solicit feedback from my peers.
So the next time you consume a mobile app, remember that there is a lot of work that goes behind this and appreciate that you don’t have to go down the hard path of building it all yourself. Anypoint Platform can help accelerate your journey towards your mobile strategy. Try API Designer for yourself by registering for API Portal.
