Usage

• The README contained everything I needed to easily use the program:

• The program compiles/runs without errors:

• The program worked as advertised:

Style

• The code is cleaning divided into modules and multiple files:

• Variable and function names are meaningful:

  Be consistent with naming conventions. You mostly use CamelCase, but the do_GET uses underscore_case

• Comments are used where appropriate:

  More descriptive docstrings would be helpful, as well as docstrings for methods. Would also allow for automatic documentation generation!

Philosophy

• The program most closely follows the mvc interface pattern:

  nice separation of model, view and controller. I think the controller could be improved to be a little more general, with fewer explicit if/else checks. It would be cool if you could define a text file with uri-path->action mappings and have the controller load that for more customization.

• This choice of pattern is a good one for this application:

• This program follows the Rule of Silence and Least Surprise:

• This program follows the Rules of Modularity and Composition:

  The controller code should probably be split off into a separate module so it could be more easily used independantly from the current server and program.

• This program follows the Rules of Representation and Simplicity:

  Nice job with this, I was able to add my own data type to outline.yaml and it worked! But it does look like you are artificially restricting the structure of the data that can be used, when I initially tried a data type with nested structures I got an error. Rather than try to coherce the input data into a flat list of key/value pairs, why not just store whatever the JSON parser gives you?