<commit_before># vanilli

[![Build Status](https://travis-ci.org/kelveden/vanilli.png?branch=master)](https://travis-ci.org/kelveden/vanilli)
[![Dependencies Status](https://david-dm.org/kelveden/vanilli.png?branch=master)](https://david-dm.org/kelveden/vanilli)

> IMPORTANT: In it's *very* early stages. Expect the goalposts to move. A lot.

A RESTful server running on Nodejs for storing and matching stubs/expectations from a test run.

## Usage
Whilst vanilli exposes a RESTful API (which is documented below), it'll probably make more sense to talk to vanilli from its
javascript client library cousin https://github.com/kelveden/milli. You can also hook starting/shutting vanilli down into your grunt build
with https://github.com/kelveden/grunt-vanilli.

See the milli tests and its Gruntfile.js for an example of how milli, vanilli and grunt-vanilli fit together.

## REST API
### GET _vanilli/ping
Produces: _application/json_

Simple ping/pong for the server.

### POST _vanilli/stubs
Consumes: _application/json_

Accepts one or more stubs/expectations for storage.
The body should be a single stub definition OR a JSON array containing one or more stub definitions. A stub definition takes the form
given below. (Note that all fields are optional unless otherwise specified):

    {
        criteria: {
            url: _url to match against - can be a string or regex_, -- MANDATORY
            body: _the request entity body to match against; can be a literal or a regex,
            contentType: _the request entity content type to match against; i.e. Content-Type header_,
            query: {
                _param1_: _expected value; literal or regex_,
                ...
            },
            headers: {<commit_msg>README stuff.<commit_after># vanilli

[![Build Status](https://travis-ci.org/kelveden/vanilli.png?branch=master)](https://travis-ci.org/kelveden/vanilli)
[![Dependencies Status](https://david-dm.org/kelveden/vanilli.png?branch=master)](https://david-dm.org/kelveden/vanilli)

> *IMPORTANT*: Before considering using vanilli or milli there is a reliance on CORS that may be a gotcha for you. See the section on CORS below for more info.

A RESTful server running on Nodejs for storing and matching stubs/expectations from a test run.

## Usage
Whilst vanilli exposes a RESTful API (which is documented below), it'll probably make more sense to talk to vanilli from its
javascript client library cousin https://github.com/kelveden/milli. You can also hook starting/shutting vanilli down into your grunt build
with https://github.com/kelveden/grunt-vanilli.

See the milli tests and its Gruntfile.js for an example of how milli, vanilli and grunt-vanilli fit together.

## How It Works
Vanilli is designed to act as a "fake" version of the REST service(s) that your SUT depends on. It sits running on a port (say 14000).
Your SUT will be running on another port (say 8080). Most importantly, you will have configured your SUT so that HTTP calls to
REST services go out to port 14000 NOT 8080.

Now, all you need to do is set up stubs in vanilli (i.e. with milli) so that appropriate responses exist when making calls to the
fake REST services.

### CORS
As you might have worked out, this architecture relies heavily on CORS. Vanilli will send out CORS headers in all responses:

    Access-Control-Allow-Origin: *
    Access-Control-Allow-Headers: <See lib/cors.js for a list of the supported headers>
    Access-Control-Allow-Methods: <HTTP methods for all the stubs for the resource that vanilli knows about>;

Extra headers for the `Access-Control-Allow-Headers` header can be added via `config.allowedHeadersForCors` which is a JSON array
of HTTP headers.

> *IMPORTANT*: This reliance on CORS means that the browser that you are running your tests on MUST support and be configured to support CORS.

## REST API
### GET _vanilli/ping
Produces: _application/json_

Simple ping/pong for the server.

### POST _vanilli/stubs
Consumes: _application/json_

Accepts one or more stubs/expectations for storage.
The body should be a single stub definition OR a JSON array containing one or more stub definitions. A stub definition takes the form
given below. (Note that all fields are optional unless otherwise specified):

    {
        criteria: {
            url: _url to match against - can be a string or regex_, -- MANDATORY
            body: _the request entity body to match against; can be a literal or a regex,
            contentType: _the request entity content type to match against; i.e. Content-Type header_,
            query: {
                _param1_: _expected value; literal or regex_,
                ...
            },
            headers: {
{'fraction_non_alphanumeric': 0.07402680280791321, 'fraction_numerical': 0.0042544139544777706, 'mean_word_length': 3.486641221374046, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 8, 'https://': 12, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2904530', 'n_tokens_mistral': 1369, 'n_tokens_neox': 1287, 'n_words': 590}