Working With MediaWiki

APIs require a “key”, placed within the URL, which serves as an identifier in order to prevent public abuse of the API. In some cases, this key is meant to be a secret; when that happens, it wouldn’t work to place the full URL of the API directly within the wiki page. For that reason, External Data also allows the use of secret strings, whose real value is defined within LocalSettings.php. So if you want to access an API whose URLs are in the form “http://worlddata.com/api?country=Guatemala&key=123abc”, you can add the following to your LocalSettings.php file, after the inclusion of External Data:
$edgStringReplacements['WORLDDATA_KEY'] = '123abc';
    After that, you can instead place within the wiki URLs like:
http://worlddata.com/api?country=Guatemala&key=WORLDDATA_KEY
    ...and the replacement will happen behind the scenes.
    If you’re a security-minded individual, you may have already thought ahead to a possible counterattack that a malicious user could do to find out the actual value of a secret string: put somewhere in the wiki a call to #get_web_data, pointing to a URL in a domain that that user controls, that also contains the replacement string. Then the user just has to check that domain’s server logs to find out the true value. Thankfully, a defense exists for this: you can create a “whitelist” of domains for External Data, so that only URLs contained within that list can get accessed by External Data.
    To create a whitelist with multiple domains, you should add something like the following to LocalSettings.php, after the inclusion of External Data:
$edgAllowExternalDataFrom = array( 'http://example.org', 'http://example2.com' );
    And if the whitelist has only one domain, you can just have something like this:
$edgAllowExternalDataFrom = 'http://example.org';
Getting data from a database
    Data can also be retrieved from databases, using the call #get_db_data. #get_db_data can access any database systems that MediaWiki can access; currently that group is MySQL, PostgreSQL, Microsoft SQLServer and Oracle. The process for each of them is the same. First, the login information to access any particular database has to be added to LocalSettings.php (after the inclusion of External Data), in a format like this one:
$edgDBServer[' database ID '] = " server name ";
$edgDBServerType[' database ID '] = " DB type ";
$edgDBName[' database ID '] = " DB name ";
$edgDBUser[' database ID '] = " username ";
$edgDBPass[' database ID '] = " password ";
    Here the string “database ID” is an arbitrary ID for the database; it can be any string. You can set information for as many databases as you want to in LocalSettings.php, with a different ID for each.
    The call to #get_db_data then takes the following form:
{{#get_db_data:db= database ID |from= table name |where= filters |data= mappings }}
    The idea is the same as for #get_web_data, though the parameters are different. The
db
parameter holds the database ID, which is defined in LocalSettings.php. The next two parameters are based on elements of the “SELECT” statement in SQL, if you’re familiar with that. The
from
parameter holds the database table name, or a join of tables if there’s more than one; it’s the equivalent of a SELECT statement’s FROM clause. The
where
parameter holds the filters, or the set of conditions that we are restricting results on, with each filter separated by " AND "; this is equivalent to the SELECT statement’s WHERE clause. Just as with #get_web_data, the
data
parameter holds the set of fields we want to retrieve, along with the mapping of a local variable for each field. It’s also similar to a SELECT statement’s SELECT clause, though not identical.
    Here’s an example of a #get_db_data call — this one retrieves some information about a room in a building whose name is the same as the current page name:
{{#get_db_data:db=myDB
|from=rooms r JOIN room_status rs ON r.room_status_id = rs.id
|where=r.name={{PAGENAME}}
|data=capacity=r.capacity, building name=r.building, status=rs.name
}}
    Note that table aliases (here, "r" and "rs") can be used, just as with a SQL statement.
    There are some additional parameters that can be passed in to #get_db_data:
limit=
— adds a “LIMIT” clause to the SELECT statement, setting the number of values to be returned.
order by=
— adds an “ORDER BY” clause to the SELECT statement, setting the order of results.
group by=
— adds a “GROUP BY” clause to the SELECT statement,