In the first of a new series, we bust the jargon of the development world, starting with all things API-y…
API
“Application Programming Interface”
APIs are the WhatsApp of the development world, allowing different applications – from operating systems like Windows to fart sound effect mobile apps – to speak to each other and share information.
In website development, APIs are typically used to pull content from other services across the web, such as integrating a Twitter feed or embedding a bespoke Google Map on your page.
Your site will speak to the service in question using a secret key (password) to verify the request, then data will be returned in a raw format (such as XML or JSON, see below) by the API – a program written by the service-provider specifically to handle such external requests.
This process is slightly different to, for example, embedding a YouTube video using copy-and-paste code, although the concept is the same – you are borrowing another site’s content. But with an API, the data returned is usually customised to a greater extent and can be used in a less restricted way.
For instance, as well as showing your business location on an embedded map, you could ask customers to enter their postcode on your website, send this to Google along with your office address, then show the customer step-by-step travel directions right on your own page.
As well as content, APIs can be used to import visual elements (such as an external font) or libraries of interactive effects (the most well-known being jQuery).
Not to be confused with… PPI, ‘programmer-programmer interface’, which is two developers having a chat.
XML / JSON
“Extensible Markup Language” / “JavaScript Object Notation”
First of all, yes, ‘extensible’ is a word – it kinda means the same as ‘extendable’ but without the connotation of dining tables or hedge trimmers.
XML and JSON are two examples of coding formats that allow information to be shared between applications. XML is what powers RSS feeds (an example of a very simple API) such as this one from the BBC News website. Meanwhile JSON is a format used by the JavaScript language to encode complex information so it is safe for transmission as a single line of text (a process known as serialization).
The idea of both of these markup (web code) formats is that they deliver data in a basic and clean format, which can then be adapted however the application reading them requires.
If you look at raw XML or JSON code, it is usually possible to read the text content, but it will be encased in tags (XML) or punctuation marks (JSON), as seen in this handy example of both.
The code tells the website or app reading the feed how the data should be structured, but leaves it up to the developer to decide how to present it, hence the ‘extensible’ concept, as in ‘I’m going to extense this XML feed into a news page to the best of my extensing abilities.’
Not to be confused with… Jason, an ice hockey mask-wearing mass murderer. Remember, JSON = serialization, Jason = serial killer.
Arrays and Objects
In the examples of XML and JSON markup linked above, you’ll have noticed that the data isn’t all on the same level – some lines are indented, like a multi-depth bullet-point list in Word, and seemingly enclosed within other lines by tags or curly brackets (‘braces’).
This is how the serialization formats denote groups of data. These groups are then interpreted by the website accessing them as either ‘arrays’ or ‘objects’ (the difference is largely academic, so I’ll just call them arrays from now on), which can then be shown in order, counted, re-arranged or anything else you might do with grouped information (like the sheets of paper in a binder).
You can also ‘nest’ arrays within one another array to create a hierarchical structure. For instance, an RSS blog feed might be an array of 10 posts, or ‘parents’, each of which has a ‘child’ array with data entries for the title, content, author and so on. There could be further subset arrays in each post containing the category list, external links and so on. These sub-arrays can also be arranged as needed (you could imagine them like post-it notes stuck to the binder’s pages, with smaller post-its stuck of those in turn, and so on).
There is no limit to the number of nested arrays you can have, but a good API will use a logical structure and the call made by your website to the API will ideally only ask for the data you need – the whole purpose of APIs is to compile data in the most efficient way (i.e. letting someone else do a lot of the work for you), so structure is very important.
Not to be confused with… ‘Hooray’s, usually called Henry, upper-class twits living the high life. Hoorays do arrange themselves into hierarchical structures and subsets, but unlike serialized arrays they very rarely serve a useful purpose.