This page
Other pages
You are viewing an old version (v. 17) of this page.
<< View previous version | view page history | view next version >>
FAI data API
An API is an Application Programming Interface
. All sorts of people need FAI data and it should be delivered in a consistent form. FAI needs an API!
This is a very simple example of the sort of data FAI should make available for people to use in their applications.
Select items below to include that data in the resulting XML data output, then press get XML.
In a web browser this data is presented in a tree-like structure, that is what XML is. You can use the little - and + icons on the left side to collapse and expand different elements in the tree.
To return to this page, simply press the back button.
More from this API
When you are looking at the XML, look at the URL - it contains the requested parameters.
The key to this API is what is in the URL after the ?
The examples above are just a small subset of what is available from an API like this, for example records for all microlight and paramotor classes are available, eg ?data=cima.records.PL1E will get you class PL1E. (inspect the list of classes and use the <class_name> field.)
This API is also set up to get other subsets, for example ?data=cima.records.P will get you all records in the paramotor classes or ?data=cima.records.1E will get you all records in electric classes flown solo.
You can do the same with the class list, as in ?data=cima.classes.P and ?data=cima.classes.1E
With the keyword "all" you can get the lot, as in: ?data=cima.classes.all and ?data=cima.records.all In this latter case it is quite a big data set which might take a bit of processing, hence the options above are probably more useful most of the time.
You can get two or more datasets simultaneously by concantenating them with ampersands: & as in: ?data=cima.records.WL1&data=cima.records.PL1E
Members
This API supports subsets of FAI members by continent, so ?data=members.europe will get European FAI members. It will also do partial matches, so ?data=members.asia will retrieve members from East Asia and South Asia.
Note that in all cases the URL must be properly encoded, so the url for South America, which has a space in it, should be:
?data=members.south%20america
CIMA Delegates
As with FAI members, This API supports subsets by continent for delegates the same as it does for FAI members, so
?data=cima.delegates.europe will get European CIMA Delegates.
Making it pretty
This kind of data is primarily there for people to automatically download and re-process in useful and interesting ways but XSLT transformations can also be used directly to make it look pretty in a browser, and this is implemented in this API by adding &xsl=1 to the URL, for example?data=members.america&xsl=1 displays all FAI Members from the Americas in a user-friendly format.
What this is
What you have here is a simple RESTful web service delivering read-only data (Technically, it is a GET). The data itself is presented in a pre-defined xml
format.
Since there is no security in this demo only public domain information is available but with a permissions based secure system more information could be supplied such as addresses, phone numbers Etc.
With API's like this it is also possible to send data the other way. (PUT or POST) or DELETE. For these latter actions some form of security is also obviously required. An experiment with oAuth to secure this API is coming soon.
Purpose
The purpose of all this is just a simple demo to show the possibilities of the sort of data FAI should be making available, and a simple API to get it.
Several things will be noticed:
- No secure data is exposed, eg email addresses. For this sort of thing a level of permissions is required.
- There should however be a lot more info, eg NAC names Etc which is not contained in this demo database.
- The primary objective of an API like this is data supply. It is not necessary for it to be able to deliver every possible query, for example the name of the NAC under which a World record was ratified, but it is necessary for it to deliver sufficient data that this could be determined from further processing. In this case the <fai_nation/> field would be used to join the two data sets.
- Since an API like this is designed to be called often, it is a good idea to have subsets which are capable of delivering reasonably small amounts of data. No point in delivering all 500+ microlight records if only the ones for a single class are needed.
- All data is encapsulated in a single <fai></fai> structure. While the whole purpose of this sort of thing is that it should be extensible, it would be very wise for FAI to create a basic structure which deals with the core data elements. The range of applications are vast, way more than this little demo and include sporting licences, competition entry lists, tracks, tasks, results... If all FAI associated data had a documented basic core structure then we are well on the way to having something really useful.
- Standard format allows data to go in different directions with some confidence that it will be understood by the recipient - for example it becomes easy to load competition results in a common format to the FAI website Etc.
- While it is recommended the <fai/> structure should be used to encapsulate everything possible, it should also be realized that there are some other formats commonly used for some things, eg iCalendar for calendars, RSS for news and .igc for track files.
- When structured data like this is available, people will start using it in ways FAI never imagined. Since the data we're talking about is all in the public domain already - it can only be a good thing for FAI.
Recommendation
There are many opportunities for structured FAI data, but there is no structure.
It is strongly recommended a FAI wide Working Group is set up to establish this FAI structure.