Finish first pass at enhanced swagger-router mock mode

[whitlockjc]

swagger-router mock mode needs to implement support for the following:

• Response headers
• Response type format/constraints
• Handle non-JSON response types

[borisirota]

+1

[whitlockjc]

I have a few ideas about this that I would like to discuss. One thing we need to do account for a response's examples property in this process. To do that we would need to finish #134 and add validation to examples like we currently do for default values. After that, we'd likely need some way to register type/format/constraint specific "handlers" that would be consulted because it is very unlikely we'll be able to infer enough information to support this completely. Here are my current concerns:

• Response headers: Should be no big deal
• Response type format/constraints: Should be no big deal for built-in types/formats/constraints but for custom types, what would we do?
• Handle non-JSON response types: There are so many things that could impact how a non-JSON type could be created...how do we handle them?

I'm looking for your thoughts on this if you have the time.

[borisirota]

I like taking into account the examples 👍

In addition, I'm facing 2 custom use cases that the swagger doesn't support so this is my 2 cents:

• constraints (I'm guessing you mean to additional vendor properties on schema object like minimum, pattern, etc. - for example - x-notEqualsTo) - I have an equalsTo and notEqualsTo validation checks - in order to support mock value for that I'm thinking of registering the following function:

function mockNotEqualsTo (suggestedValue, object, notEqualsTo) {
    // if string
    return suggestedValue + ((object[notEqualsTo] === suggestedValue) ? 'suffix' : '');
    ...
}

This function getting the suggested mock value, the mocked object, the value of the constraint (x-notEqualsTo: name) and returning the new mocked value (if needs to be changed). In my example, there is a problem when the x-notEqualsTo points to a property that hasn't been mocked yet. for example:

properties:
    name:
        type: string
        x-notEqualsTo: password
    password:
        type: string

So maybe setting the custom "handlers" after the default mock is ready?

Anyway, this function can be passed inside the handlers object with the key notEqualsTo.

• custom format - I'm using mongoose and their internal id's. these id's are of kind ObjectID (length of 24 chars I think). So I'm setting this param as:

properties:
    id:
        type: string
        format objectId or uuid

And the function will be:

function mockObjectId (suggestedValue) {
    return suggestedValue.length === 24 ? suggestedValue : 'A23Fvde5h0rfDn71Hjnv9w5s';
}

The issue here is naming the key in the handlers object so maybe combination of type_format -> string_objectId ?

If passing these handlers to the router so I guess it will look like this:

swaggerMiddleware.swaggerRouter({
    useStubs: true,
    mockHandlers: {
        notEqualsTo: function mockNotEqualsTo (suggestedValue, object, notEqualsTo) {
            // if string
            return suggestedValue + ((object[notEqualsTo] === suggestedValue) ? 'suffix' : '');
            ...
        },
        string_objectId: function mockObjectId (suggestedValue) {
            return suggestedValue.length === 24 ? suggestedValue : 'A23Fvde5h0rfDn71Hjnv9w5s';
        }
    }
})

I'm working only with json so no idea what to do with other formats :)

I hope I understood what are you asking about :)

[whitlockjc]

That's a cool idea. You'd have a registry of mock handlers that can be used to create the values with formats unknown. Seems reasonable.

But this doesn't help with the non-JSON formats. Maybe this is a good enough step in the right direction. I'll give it some thought.

[whitlockjc]

I am going to close this and create a better explanation of what is needed.