We're looking for more developers. Want to contribute? Join the Mailing List and introduce yourself, or contact Bruce Damer directly.
Latest News
ALife XII CompOrigins call for papers.

Prototype2009: Simulation Manager API

From The EvoGrid: The Evolution Technology Grid

Jump to: navigation, search


General Design

The Simulation Manager is implemented as JSON transferred over HTTP requests. This uses GET and PUT to retrieve or submit information, with any information not in the URL to be in HTTP headers.

All requests start from a base URL. On the development server, this is


This URL uses Apache mod_rewrite to convert to


and is just shortened for neatness. In the Alpha 10-01 VM Images, the path is

When accessed directly, the base URL produces a human readable status page.

The URL used to access a resource follows a pattern of

 [base_url]/[simulation id]/[property]

Additionally, [simulation id] can be the magic word "pending". Property can be

  • parameters
  • history
  • statistics
  • scores

For example:

Providing a incorrectly formatted simulation id will return a HTTP 400 - Bad Request.

Redirect means - Provides a HTTP 302 response, and provides a Location: header.

When using a GET request, if the data is not available, returning HTTP 404 is the standard response.

See Prototype2009: Data Formats for the JSON used in these requests.



  • pending - Will redirect to a simulation id that hasn't been simulated
  • simulation id - Will provide the parameters for the specific simulation


  • pending - Will redirect to a simulation with a history but no statistics
  • simulation id - Will provide the history for the specific simulation


  • pending - Returns HTTP 400, pending is not valid for statistics
  • simulation id - Will provide the statistics for the specific simulation


  • pending - Requires the X-Search-Score header be included in the request. This will return the scores for a simulation that has scores, but not the X-Search-Score
  • simulation id - Will provide the scores for the specific simulation


Unless specified, use of pending will return HTTP 400.


  • pending - Will submit the simulation parameters as a new simulation

All other parameters (like a simulation id) will return HTTP 400.


  • simulation id
    • If simulation already has a history, returns HTTP 403 (Forbidden).
    • Otherwise, history is stored


  • simulation id
    • If simulation doesn't have a history, returns HTTP 403 (Forbidden)
    • Store statistics, discarding duplicates of already know statistics
      • While in development - If statistic name is not recognized, it is added as a new type of statistic


  • simulation id
    • If simulation doesn't have a history, returns HTTP 403 (Forbidden)
    • Store scores, discarding duplicates of already known scores

Future Developments

  • Require identifiers/accounts for PUT actions, for logging and security (prevent poisoning).
  • Use multiple sources for all processing that is farmed out (prevent poisoning).
  • Break searches separately from scores.
    • Have searches require sets of scores, specified server side.
    • Concept: /pending/search/search-identifier rather then X-Search-Score ?
  • PUT /pending/parameters will include which search it's being submitted for.
  • GET /[simulation id]/ (without parameters/history/statistics/scores/etc) will return a human formatted status page for that simulation
  • Human readable pages could use a microformats concept to remain machine parsable?
Personal tools