exactly_one_of and mutually_exclusive seem not to work in a group

[klaustopher]

Hi there,

I'm currently creating an API with the stable version (0.8.0) and one of the endpoints should get some nested params of which I only need one.

class RatingService < Grape::API
  version 'v1'

  namespace :ratings do
    desc 'Rates an Artist or a Song'
    params do
      requires :rating, type: Hash do
        requires :value, type: Integer
        optional :artist, type: String
        optional :song, type: String
        exactly_one_of :song, :artist
      end
    end
    post do
      puts params.to_yaml
      { message: 'Rating created' }
    end
  end
end

When I send data to the API, I get the following error:

# POST http://localhost:3000/api/v1/ratings.json
# body:  { "rating": {"value": 12, "aritst": "Some Artist"} }
HTTP/1.1 400 Bad Request

{
    "error": "[:song, :artist] - exactly one parameter must be provided"
}

It works fine, if I put the artist field on the root of body, but that is not what I'm intending.

Is there a special syntax that needs to be used, when defining an exactly_one_of or mutually_exclusive constraint for nested params, or is this a bug?

[dblock]

Are you posting with the correct content type 'application/json'?

[klaustopher]

Yes, here's the request I'm making (using the HTTPie command line utility): http --json --print HBhb POST http://localhost:3000/api/v1/ratings rating:='{"value": 12, "artist": "Some Artist"}'

Request Headers:

POST /api/v1/ratings HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Content-Length: 52
Content-Type: application/json; charset=utf-8
Host: localhost:3000
User-Agent: HTTPie/0.8.0

Request Body:

{
    "rating": {
        "artist": "Some Artist",
        "value": 12
    }
}

Response Headers

HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 70
Content-Type: application/json
Server: thin 1.6.2 codename Doc Brown
X-Request-Id: 79ed36dc-f713-40c2-a27b-9f4dabd68677
X-Runtime: 0.469464

Response Body

{
    "error": "[:song, :artist] - exactly one parameter must be provided"
}

[oliverbarnes]

Could it be because of this typo?

"aritst": "Some Artist",

[klaustopher]

That would have been incredibly embarrassing, that was just copy and paste error, sorry. Fixed it in the example above.

[dblock]

Try to write a spec for this?

Need to look at the value of params here.

[klaustopher]

I guess the problem is in the way, the params are passed into the MutualExclusionValidator. Looking at MutualExclusionValidator#keys_in_common, it compares the provided keys with the keys in the params mash without regarding the scope in which it was defined ...

In my case it tries to find the keys ["asset", "artist"] in ["rating", "route_info"]

One thing I find odd, is that all other validations provide a validate_params! method that is called by Validator#validate! in the correct way (within the right group) but MutualExclusiveValidator and ExactlyOneOfValidator override the validate! method and don't handle the scope themselves.

[oliverbarnes]

yes, I remember making the choice back then. Must have assumed this mutually_exclusive wouldn't be used in a nested context, somehow. If you could provide a spec like @dblock suggested, I can take a look at it soon

[dblock]

This now explains #688.

[klaustopher]

I pushed a spec for the behavior in #702, might have a look at it, if time allows for it

[oliverbarnes]

thanks @kgz, I've been working on it since yesterday. Scratching my head looking at AttributesIterator and ParamsScope trying to figure out how to get at a certain group of params.

It seems like AttributesIterator doesn't fit here, since it iterates on attributes and params one by one?

My impression is a ParamsIterator would be more like it in the case of mutually/exactly_one/at_least_one, since we're comparing groups of attributes to groups of params?

If so, do you guys see a clear way to iterate through each group of params with the current ParamsScope code?

[klaustopher]

I've taken a look at it, and I have to say, it's not that easy to grasp how everything is tied together when I looked at it for a few minutes. By my first look at it, it seems that it's not that easy to accomplish without changing a lot of the logic in the Validator Base. I might have some more time to dive into the codebase on the weekend