Web APIs and Frameworks

Icon


Contents:

1   Overview
2   KayFish
3   Twilio
4   jQuery
5   Modernizr



1. Overview.

This document is preliminary. However, it may be of interest to developers working with Web APIs and/or Web frameworks of various types.

This document will contain or link to quick-start and/or smoke-test procedures that I've used in these contexts. It may eventually add tips related to development and debugging.

Note: If you're interested and notice inaccuracies, drop me a line.





2. KayFish.

As of May 2012, KayFish was billed as a “new PHP / MySQL framework”. The home page was:

https://github.com/freekrai/Kayfish

and the code could be transferred to a standard Linux development system using:

git clone https://github.com/freekrai/Kayfish.git

Towards the end of May, I set up the framework and did a quick smoke-test. Here's how I proceeded. None of this is guaranteed to work for anybody else.

2.1. I created a directory named kayfish at the top level of a web-server documents tree on a local server.

2.2. I cloned the KayFish sources into the new directory using the git clone command indicated above. Subsequently, I renamed htaccess.txt to .htaccess as the README file provided in the sources directed. I also deleted the .git subdirectory as this subdirectory would not normally be present in a live copy.

2.3. I added a MySQL database for KayFish. To do this, I used a script similar to the following, setting MSQPASS appropriately for my system. Note that, for the sake of simplicity, this code sets the database name, user name, and password all to kayfish. In a production environment, different settings would probably be used.


MSQPASS=some_password   # MySQL-level "root" password

((mysqld_safe --user=mysql >& /dev/null &) || true) || exit 1
sleep 10                                            || exit 1
echo "drop database kayfish;" | mysql -u root -p$MSQPASS
echo "create database kayfish;" | \
    mysql -u root -p$MSQPASS                        || exit 1

echo "grant all on kayfish.* to 'kayfish'@'localhost';" \
    | mysql -u root -p$MSQPASS                      || exit 1

echo "set password for \
    'kayfish'@'localhost' = password('kayfish');" \
    | mysql -u root -p$MSQPASS                      || exit 1
echo Done

Note: To download the preceding code, use this link.


2.4. I uploaded the SQL definitions provided in a KayFish source file named sql.sql to the new database. To do this, I executed:


mysql kayfish -ukayfish -pkayfish < sql.sql

2.5. I pointed a web browser at the new kayfun folder; via the local web server as opposed to directly.

The server displayed a page similar to the following, which appeared to be correct:


image

Default KayFish page




3. Twilio.

Twilio is a commercial venture that provides a convenient software service: a means to perform phone-related operations over the Internet using a Web API. As of May 2012 the home page was:

http://www.twilio.com/

and the API documentation was available at:

http://www.twilio.com/docs/api/rest/

Note: The Twilio API is RESTful. This means that it meets a particular software standard that is intended to promote simplicity and efficiency.

Towards the end of May, I did an experiment based on the Twilio API. The procedure I used is explained below. None of this is guaranteed to work for anybody else.

3.1. The first step was to sign up for a Twilio-compatible API test site. This was simpler than becoming a registered Twilio developer or of going through the authentication procedure needed to obtain demo access. The site I used was:

https://twilioapi.appspot.com/

The signup process gave me an account SID and token. I noted those for later use.

3.2. The second step was to write a Perl script that did a Twilio API call. The script is shown below in browseable form. To download a text version, click here.


#!/usr/bin/env perl
# twilio120525a - Trivial Twilio smoke test
# License:  MIT/X
# Revision: 120525

#---------------------------------------------------------------------
#                              overview
#---------------------------------------------------------------------

# This  Perl script does  a simple smoke-test of  the  Twilio API.  It
# requires a  registered  account at Twilio or a  compatible  emulator
# site. To use the script,  set the $ACCOUNT_ and $API_ parameters ap-
# propriately; then execute.  If things are working  there will be XML
# output.

#---------------------------------------------------------------------
#                            module setup
#---------------------------------------------------------------------

require 5.10.1;
use strict;
use Carp;
use warnings;
use LWP;
                                # Trap warnings
$SIG{__WARN__} = sub { die @_; };

#---------------------------------------------------------------------
#                           basic constants
#---------------------------------------------------------------------

use constant ZERO  => 0;        # Zero
use constant ONE   => 1;        # One
use constant TWO   => 2;        # Two

use constant FALSE => 0;        # Boolean FALSE
use constant TRUE  => 1;        # Boolean TRUE

#---------------------------------------------------------------------
#                         program parameters
#---------------------------------------------------------------------

#  $ACCOUNT_SID   is account SID   (varies from user to user)
#  $ACCOUNT_TOKEN is account Token (varies from user to user)
#  $API_SERVER    is hostname of a Twilio-compatible API server
#  $API_PORT      is port number to use
#  $API_VERSION   is version string for Twilio API used

my $ACCOUNT_SID   = 'put the SID   here';
my $ACCOUNT_TOKEN = 'put the Token here';
my $API_SERVER    = 'twilioapi.appspot.com';
my $API_PORT      = 80;
my $API_VERSION   = '2010-04-01';

#---------------------------------------------------------------------
#                            main routine
#---------------------------------------------------------------------

sub Main
{
                                # LWP browser  object
    my $browser = LWP::UserAgent->new;
    my $request;                # LWP request  object
    my $response;               # LWP response object
    my $link;                   # URL for API request
    my $output;                 # Output buffer

    select STDERR; $| = ONE;    # Force STDERR flush on write
    select STDOUT; $| = ONE;    # Force STDOUT flush on write

                                # Create LWP browser object
    $browser = LWP::UserAgent->new;

                                # Build a  simple  Twilio request link
                                # Note: To  get JSON output instead of
                                # XML output  you'd simply add ".json"
                                # to the link constructed here

    $link = << "END";           # "END" must be double-quoted here
http://$API_SERVER/$API_VERSION/Accounts/$ACCOUNT_SID/
IncomingPhoneNumbers
END
    $link =~ s@\s+@@gs;         # Remove all white space
                                # Build LWP request object
    $request  = HTTP::Request->new (GET => $link);
                                # Set up authentication
    $request->authorization_basic ($ACCOUNT_SID, $ACCOUNT_TOKEN);

                                # Submit request and get response
    $response = $browser->request ($request);
                                # Check for errors
    die unless $response->is_success;
                                # Get output
    $output = $response->content;
                            # Format it slightly
    $output =~ s@(</\w+>)@$1\n@g;
    while ($output =~ s@(<\w+>)(<\w+>)@$1\n$2@g) {}
    $output =~ s@\s*\z@\n@;

    print $output;              # Print output
    undef;
}

#---------------------------------------------------------------------
#                            main program
#---------------------------------------------------------------------

&Main();                        # Call the main routine
exit ZERO;                      # Normal exit

3.3. The final step was to run the script. It produced XML output of the following form, suggesting that things were working correctly:

<numpages>2</numpages>
<end>61</end>
<IncomingPhoneNumbers>
<IncomingPhoneNumber>
<VoiceFallbackMethod>POST</VoiceFallbackMethod>
<SmsMethod>POST</SmsMethod>
<VoiceFallbackUrl>None</VoiceFallbackUrl>
<SmsUrl>None</SmsUrl>
<VoiceCallerIdLookup>False</VoiceCallerIdLookup>
<SmsFallbackMethod>POST</SmsFallbackMethod>
<StatusCallback>None</StatusCallback>
<ApiVersion>2010-04-01</ApiVersion>
<DateCreated>2010-11-24T09:22:09.996002</DateCreated>
<SmsFallbackUrl>None</SmsFallbackUrl>
<PhoneNumber>+11234567890</PhoneNumber>





4. jQuery.

jQuery is a cross-browser JavaScript library; i.e., a library that works with different types of browsers. It can be loaded by web pages and used to perform a range of operations. As of May 2012, the home page was:

http://jquery.com/

At the time, two versions of jQuery were available: a “compressed” version, which was not human readable, and an “uncompressed” version, which was human readable. The latter version was available at:

http://code.jquery.com/jquery-1.7.2.js

Towards the end of May, I installed the library and tried it. The steps used are listed below. None of this is guaranteed to work for anybody else.

4.1. I downloaded jquery-1.7.2.js from the location shown above. I saved the file in the top-level directory of a web-server documents tree on a local server. I then renamed it to jquery.js.

4.2. I downloaded a jQuery plugin (i.e., extension) that looked interesting: Farbtastic, which was available at:

http://acko.net/files/farbtastic/farbtastic12.zip

I unpacked the ZIP file linked here in the directory where I'd placed jquery.js. This produced two new folders named __MACOSX and farbtastic respectively. __MACOSX wasn't needed for my purposes so I deleted that folder.

4.2. I put the following HTML file in the same directory. This file was designed to use jQuery to run Farbtastic:


<html>
<head>
    <title>jQuery Test</title>
    <script type="text/javascript" src="jquery.js"></script>
    <script type="text/javascript"
            src="farbtastic/farbtastic.js"></script>
    <link rel="stylesheet" href="farbtastic/farbtastic.css"
          type="text/css" />
    <script type="text/javascript" charset="utf-8">
    $(document).ready(function() {
        $('#selector').farbtastic('#color');
    });
    </script>
</head>
<body>
<form action="" style="width:350px;">
    <div class="form-item">
    <label for="color">Click and drag:</label>
    <input type="text" id="color" name="color" value="#123456" />
    </div>
    <div id="selector"></div>
</form>
</body>
</html>

Note: To download the preceding code, use this link.


4.3. I pointed a copy of the Midori web browser at the new HTML file; via the local web server as opposed to directly. The web server displayed a page similar to the following:


image

jQuery test using Farbtastic

The color selector shown here worked as expected. This indicated that jQuery was operating correctly.




Here's a live copy of the jQuery-Farbtastic color selector discussed above. It should work for most browsers that have JavaScript:






5. Modernizr.

Modernizr is a JavaScript library that determines what features are, and are not, supported by the active browser. It can be loaded by web pages and used to simplify the construction of code that works reasonably well on different types of browsers. As of May 2012, the home page was:

http://modernizr.com/

At the time, different versions of Modernizr with varying levels of functionality were available. A full version, one that supported all of the possible features, was provided at:

http://modernizr.com/downloads/modernizr.js

Towards the end of May, I installed the full version and tried it. The steps used are listed below. None of this is guaranteed to work for anybody else.

5.1. I downloaded modernizr.js from the location shown above. I saved the file in the top-level directory of a web-server documents tree on a local server.

5.2. I put the following HTML file in the same directory. This file was designed to load Modernizr and to use it to determine whether or not the active browser supported SVG images:


<html class="no-js">
<head>
<style type="text/css" media="screen">
<!--
    div.svgno, div.svgyes { display: none  }
    .no-svg    div.svgno  { display: block }
    .svg       div.svgyes { display: block }
-->
</style>
<script src="modernizr.js" type="text/javascript"></script>
</head>
<body>
    <div class="svgno">This browser doesn't support SVG</div>
    <div class="svgyes">This browser supports SVG</div>
</body>
</html>

Note: To download the preceding code, use this link.


5.3. I pointed an Icecat-based web browser at the new HTML file; via the local web server as opposed to directly. The server displayed a page similar to the following:


image

Checking Icecat SVG support

which indicated that the copy of Icecat I used did support SVG images. This was consistent.

5.4. I followed this up with a similar test that used MSIE6. MSIE6 displayed the following page:


image

Checking MSIE6 SVG support

which indicated that MSIE6 did not support SVG images; also consistent. My conclusion was that Modernizr was working.





Hosting provided by Zymic.

For acknowledgments related to CSS and other code used, click here.

Linked or embedded works (software, books, articles, etc.) are presented under their own licenses.

Other unique content on this page, excluding screenshots, is distributed under the following license: C.C. Attribution NonCommercial ShareAlike 3.0. In some cases, screenshots are distributed under the same license. In other cases, the associated program's license applies.

image Valid XHTML 1.0