bakedbeans 0.1.4

Installation

Create a python virtual environment with your favourite tools. Then use pip to install bakedbeans:

(venv) $ pip install bakedbeans

Running

Baked Beans provides a simple command line executable to run the server:

(venv) $ baked /path/to/contents/folder
 * Running on http://127.0.0.1:3000/ (Press CTRL+C to quit)

You can specify the host name with --host and the port it binds to with --port.

Baked Beans is also built with Docker in mind. To run Baked Beans in docker you will need to mount your local contents directory as a volume. For example:

docker run -it --rm -p 3000:3000 -v /full/path/to/contents:/contents moose/bakedbeans

This will run Baked Beans in a container that will remove itself once exit, mounting the /full/path/to/contents inside the container at /contents which is where Baked Beans is configured to load the contents from.

Writing contents

Baked Beans maps URLs to file paths, adding .<method>.json to the end of the path. There are a couple of exceptions, for example if the URL ends with / it will instead add index.<method>.json.

Examples:

Request URL	Mapped Path
GET http://localhost:3000/somewhere	<base>/somewhere.get.json
POST http://localhost:3000/another	<base>/another.post.json
GET http://localhost:3000/	<base>/index.get.json

By default the contents of the file once loaded to feed back to the request verbatim.

However, if you want to get clever with the response you can write the JSON file in the bean format. Beans are just something I made up for this project and take the form of a JSON object. For example:

{
    "_bean": true,
    "responses": [
        {
            "params": {
                "product": "1111"
            },
            "contents": {
                "id": 1111,
                "name": "Product A"
            }
        },
        {
            "params": {
                "product": "2222"
            },
            "status": 203,
            "contents": {
                "id": 2222,
                "name": "Product B"
            }
        }


    ]

}

With the bean above, it is matching the response based on the GET parameters that accompany the request. e.g. http://localhost:3000/path?product=1111 would match the first response and return the value of contents. A GET param of product=2222 would match the second. If no match is found, then the first one is selected regardless.

Note also that the second response specifies a status, this allow you to specify a specific status code to use for the response. If not specified then a default value based on the HTTP method is used.

The default status codes are:

Currently only GET parameter matching is supported but header and body matching would be a nice addition as would regex of values and use of matched criteria within the content…

Hits & Misses

The above describes have things work if everything is perfect. The url matches a content file, the content file is valid JSON, and if needed a valid bean. But what happens when things don’t match up:

Content not found

404 status with a body of {"error": "content not found the/missing/path"}

Invalid content file

500 status with a body of {"error": "content invalid"}

Bean fails validation

500 status with a body of {"error": "This is one mouldy bean"}

More detailed descriptions of the error encountered can be found in the logs.