Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Dataflow

evantahler edited this page · 6 revisions

To encourage Hacking, This document is meant to help you understand the inner workings of how a request is handled by DAVE. This document is by no way inclusive of all the special cases the API might handle, but is designed to give you a good starting point for your project-specific modifications.

  1. Web Server receives request and passes request details to index.php (perhaps proxies this though a re-direct)
  2. index.php loads up required helper files and the environment from load_environment.php
    • The working directory is updated, and the core files are loaded:
      • ConnectToDatabase.php
      • CONFIG.php
      • DAVE.php
      • CACHE.php
      • CommonFunctions.php
      • GetPostVars.php
  3. CONFIG sets the environment
    • $CONFIG variables initialized
    • Object files are loaded (all files within Objects/)
  4. CONFIG starts database table initialization from DB/TableConfig.php
    • The database structure is either read from the cached db/TABLES.php file or read again from mySQL
    • The database is re-indexed at a set frequency defined in $CONFIG['TableConfigRefreshTime']. This can be set to 0 to prevent re-indexing. db/TABLE.php can be manually generated in this case.
    • If needed, db/TABLE.php is created
  5. Returning back to CONFIG, ACTIONS are loaded
  6. POST variables are initialized in GetPostVars.php. All table database columns become variables to be considered from user input, along with anything listed explicitly in $POST_VARIABLES from CONFIG
  7. Yielding back to index.php now with the environment entirely loaded, the API extracts some information about the requestor (like IP address)
  8. The request is checked against the $CONFIG['RequestLimitPerHour'] to check if rate-limiting needs to be enforced. The LOG is checked by IP address for this purpose
  9. The $PARAMS["Action"] is examined and matched to an available Action as defined in $ACTIONS
    • If the action is Private, the request should have been authenticated by providing their APIKey and Rand (a random string)
    • The developer is authenticated via a match to md5($DeveloperID.$APIKey.$Rand)
    • CheckAPIKey.php contians the above logic
  10. The Action is preformed (Actions are stored in /Actions)
    • Actions should always continue to use the global $ERROR state variable, keeping "100" as the OK message, and any other message indicating an error.
    • Output to be returned to the requestor should be appended to the $OUTPUT array.
  11. Yielding back to index.php, summary output is calculated for the user
  12. Output.php is included to format the $OUTPUT array to the requestor and is sent.
    • The output buffer is flushed here and closed so the user's connection should be closed here
  13. The log (db) is written to recording the user's action and params

Note about database design:

DAVE expects that your database is designed well within mySQL. DAVE will respect the choices in your database design and use those column attributes to manage his own data. Columns which cannot be null or which must be unique will be respected throughout the API. There are no database builders (migrations) included with DAVE. Use a tool like http://wb.mysql.com/ to help create your schema.

Reserved Variables

There are a number of "reserved" variables that the API makes use of. You may certainly read and modify these variables in your Actions.

  • $PARAMS : To be set with all relevant, sanitized user input to the API
  • $CONFIG : Holds configuration options
  • $POST_VARIABLES : Collection of names of variables the API should ingest
  • $ACTIONS : Hash of API's Actions
  • $ERROR : The globabl state variable (100 is the OK state)
  • $DBObj : The database connection object
  • $OUTPUT : The array to be formatted and returned to the user
  • $TABLES : The table description object

CRON

Also, remember that the recurring CRON task is an integral part of this API. At the very least, CRON will expire old caches and log files if you choose it to. More elaborate uses for CRON can be to act as the worked for a DB-based message queue which, for example, might send SMS messages from a "to-be-sent" table. In DAVE, Cron makes use of pre-defined Tasks. Learn more about Tasks here.

Something went wrong with that request. Please try again.