Handling an error with multiple attributes or parameters with JSON API - api-design

Question

JSON API specifies that multiple errors on an attribute/parameter should be listed separately. What is the best way to handle a single error that involves several parameters at once?
For example, let's say an endpoint accepts either bid or fold parameters, but not both (they are mutually exclusive). What should be the error response if both of parameters are submitted (GET /endpoint?bid=100.00&fold=muck)?
List the error twice, once for each attribute?
{
"errors": [
{
"status": "400",
"source": { "parameter": "bid" },
"detail": "Cannot accept both 'bid' and 'fold' parameters."
},
{
"status": "400",
"source": { "parameter": "fold" },
"detail": "Cannot accept both 'bid' and 'fold' parameters."
}
]
}
Combine the attributes?
{
"errors": [
{
"status": "400",
"source": { "parameter": ["bid", "fold"] },
"detail": "Cannot accept both 'bid' and 'fold' parameters."
}
]
}
Make one higher-level error for the entire request?
{
"errors": [
{
"status": "400",
"source": { "pointer": "/data" },
"detail": "Cannot accept both 'bid' and 'fold' parameters."
}
]
}
Some other way?

Answer 1

TL;DR version: the first one is probably right.
Neither the JSONAPI specification nor the forum details how to format errors on mutually exclusive parameters/data. It does have this:
A server MAY choose to stop processing as soon as a problem is encountered, or it MAY continue processing and encounter multiple problems. For instance, a server might process multiple attributes and then return multiple validation problems in a single response.
To rephrase your question, what you're asking is something like this: "If you include a second parameter that is forbidden when using the first parameter, is it a single error, or multiple errors?"
This suggests, in one view, that there is only one error - Cannot accept 'bid' when using 'fold' (or alternatively in the opposite direction, if you care about ordering), and that error would only point at one parameter, since you can't encounter that error until you've processed one of the parameters.
More practically, you're checking that you have both of them at once, and encounter the error not because you had one parameter and then encountered the other, but because you know you have both parameters and now have to deal with that problem. This is still a single error, pointing at two parameters (this is the premise of your question).
The JSONAPI spec for Error Objects indicates this:
parameter: a string indicating which URI query parameter caused the error.
Since you must use a string (not Array) to indicate the source of the error, and the error is in the parameters and not the request body, you have a choice of viewing this as I laid out above to call this a single error caused by only one of the parameters, or the same error equally attributed to both parameters, as you do in your first example.
Personally I prefer to view this as a single error caused by whichever parameter comes last in the query string, but your first option is probably most correct.

Answer 2

Plan A suffers from the fact that resurrecting the full context of error is now pushed to the caller. For example, if the caller fixed one error and the other "magically" disappeared - that could be potentially confusing.
Within Plan A, you could add meta option to point out the cross-linkage as some extra help.
Plan B in comparison feels correct as it captures the essence of the error scenario (multi-parameter) plus pins them down concisely. Naturally, you will also need to request an API enhancement, probably requesting for an array of source. For example:
"source" : [ {parameter...}, {parameter...} ]