Required Parameters Feature Suggestion

[kortina]

Our team found it useful to have the ability for the stubb server to assert parameters with a particular name existed--in many casses, we find this as important as a request having the correct path. We made some small edits to create this feature.

I'm not sure if this is within the scope of what you intend stubb to do, but I wanted to ask if you would like to merge in the changes. They are here:

https://github.com/kortina/stubb/commit/a3f64c468f20ad2c2302a1a4f04f145de804146d

[knuton]

I see how this would make sense as a feature. It is quite specific to your use case, though. Other people may want to put different constraints on requests. I wouldn’t want to add a range of special cases for that.

Maybe the concept could be generalised to something like [guards](http://en.wikipedia.org/wiki/Guard_(computer_science)) for requests (no idea how best to do that, yet). I might also add your feature and only try to find a common solution once other constraint suggestions come in.

I won’t have time to look into this before next weekend. If you have any suggestion what a more general constraint concept could look like, do let me know.

[knuton]

I think the simplest more general solution would be to view request method, path and accept header analogous to a function signature as happens now. Then within the file the concept of guards can be added to refine the response based on further request information.

My idea would be to add some sort of syntax for optionally noting down header data that the request is then matched against. The first part of the file that matches is used as the response. If nothing matches, the fall-through response is a 404.

A response file whales/narwhal.GET.json might look like:

<<<<<<<
GET /whales.json?limit=1 HTTP/1.1
>>>>>>>
[{"name":"Moby"}]
<<<<<<<
GET /whales.json?limit=2 HTTP/1.1
>>>>>>>
[{"name":"Moby"}, {"name":"Monstro"}]

This would respond with a 404, unless limit is 1 or 2. In your case you probably don't want to settle on any specific value for limit, so some kind of pattern matching with wildcards should be in place. This could be made very intricate, with ranges for values and what not, but it is probably best to think of some simple first solution that is extendable if needed.

The upshot of this approach is that it is fit for other similar use cases. Say you want your response to depend on some custom header field you set:

<<<<<<<
GET /whales.json HTTP/1.1
X-Custom-Field: foo
>>>>>>>
This is the positive response.
<<<<<<<
GET /whales.json HTTP/1.1
>>>>>>>
This is the negative response.

What do you think?