Deal with (optional) headers

[MichielDeMey]

Let's try and start a discussion about (optional) headers.

In my use-case, you have to specify your language through the Accept-Language header and depending on the selected language, the response is different.

+ Request
    + Header
            Accept-Language: en-US

+ Response 200 (application/json)
    // English response

+ Request
    + Header
            Accept-Language: nl-BE

+ Response 200 (application/json)
    // Dutch response

One thing I noticed however is that drakov will return a 404 if the header doesn't match the one specified in the blueprint. However, in my API the Accept-Language header is optional and will default to en-US if undefined.

Let's discuss two things:

• Separate responses for different headers
• Replying with the default (first) response when the header is not present.
• Define which headers could be optional (by default) and allow an option to define which headers should be optional

[yakovkhalinsky]

@MichielDeMey I've had a brief discussion with my colleagues about this and we feel that making the header matching less strict would complicate the rules around response/request pair matching.

I think that being specific with the headers allows you to get a more predictable response from Drakov.

[MichielDeMey]

Makes sense, however, does Drakov currently support use-case 1 (example suplied)?

In that case I can define a response without an active header and treat that as the default response.

[yakovkhalinsky]

Yep, absolutely.

We have a test Blueprint file we test against to ensure behaviours against headers:
https://github.com/Aconex/drakov/blob/master/test/example/md/headers.md

Let me know if you have any trouble with the headers 👍

[MichielDeMey]

Just tested this, works as expected. :)
Simply specifying a response without a header will treat it as the default response in case a header is not present.

[alexborisov]

Just a quick thought, but would it not make sense to at least return something besides a 404? Technically the resource IS found, it's just the request was incorrect...

[oklaiss-gpsw]

Returning something other than a 404 would be a lot more useful, simply getting 404's back doesn't provide any useful information about what is actually wrong.