Long-term improvements to experiment server

From @suchow on April 13, 2016 9:52

There are a number of improvements that can be made to custom.py in the long term that will improve its organization, decrease the number of lines of code, be more idiomatic, and better align with conventions for APIs:

• Most of the GET and POST requests use try/catch statements that first try to perform some operations and then, if they fail, return an error. Flask recommends using this pattern: http://flask.pocoo.org/docs/0.10/patterns/apierrors/. We could also create a decorator function that automatically wraps each route's internals with a standard pattern that tries to perform given operations, returns the result if it's a success, and returns an error if it's not. This would save maybe 300 lines of code. It's good to handle errors gracefully, but having every route's structure dominated by error handling weakens the code's readability.
• request_parameter is big and complicated and can probably be eliminated entirely at some point by using existing functionality within Flask & Python. Just an example, the following code:

    try:
        value = request.values[parameter]
    except KeyError:
        # if it isnt found use the default, or return an error Response
        if default is not None:
            return default

can be written as value = request.values.get(parameter, default).

• worker_function is too long and should be refactored.
• The API should consistently return JSON when it is requested. Right now, errors return HTML even if JSON is requested, and return JSON even when HTML is requested.

Copied from original issue: berkeley-cocosci/Wallace#304

Start by reading custom.py, focusing on the route handlers, request_parameter, and worker_function. Compare the error-handling approach with Flask's API error pattern and review how routes choose HTML or JSON responses. Done means the listed refactors are addressed and API responses consistently match the requested format.