Is there a problem stubbing URLs with query params?

[matthewsinclair]

I have two pieces of otherwise identical code except for the URL being stubbed:

stub_request(
    :get, 'http://api.url.com/api/v1/tags/popular').
    to_return(json: SOME_JSON_1)

and

stub_request(
    :get, 'http://api.url.com/api/v1/tags/popular?count=1').
    to_return(json: SOME_JSON_2)

I can't seem to get the second version to work. Any :get to the second URL is not working, whereas the first one works perfectly. I'm obviously doing something stupid, but I can't work out what it is.

Any help much appreciated.

[nathankot]

@matthewsinclair I've added a simple test to check that query string works: 285f526

My rubymotion is outdated (3.13) but it passes, might be worthwhile to check if the test suite passes on your machine too.

Otherwise I would imagine it's related to the way you're making the request, could you post the code or dump of the NSURLRequest?

[matthewsinclair]

Yeah, you're right. That does work. And I'm on 3.14. So I must be doing something super stupid. I'll try to get a dump of the NSURLRequest.

[matthewsinclair]

Ok, dumb question: how do I get access to the NSURLRequest with AFMotion? I am using an AFMotion shared client like this:

        def client
          @client ||= begin
            AFMotion::SessionClient.build_shared(api_url) do
              session_configuration :default
              header "Accept", "application/json"
              response_serializer :json
            end
          end
        end

And then making a get request like this:

        client.get(uri, params) do |result|
          # do stuff with result
        end

There doesn't seem to be an easy way to get the NSURLRequest that I can see.

[matthewsinclair]

Don't worry. I ended up using AFNetworkActivityLogger to see what was being requested.

It turns out, that my request for http://api.url.io/api/v1/tags/popular?count=1 ends up being sent out by AFMotion (and/or AFNetworking underneath) as http://api.url.io/api/v1/tags/popular?count=1&.

Note the extra & at the end. I'm not sure why this happens. But at least I know that it is happening now and I can work around it.

[nathankot]

Thanks for that report :) I'll make an update where extraneous &'s are stripped

Nathan Kot

On 21/08/2015, at 09:22, Matthew Sinclair notifications@github.com wrote:

Closed #30.

―
Reply to this email directly or view it on GitHub.

[nathankot]

@matthewsinclair 1.1.3 is out that fixes this

[matthewsinclair]

Ok. Thanks! Much appreciated.

On 21 Aug 2015, at 1:40 pm, Nathan Kot notifications@github.com wrote:

@matthewsinclair 1.1.3 is out that fixes this

—
Reply to this email directly or view it on GitHub.

[matthewsinclair]

Quick question: was that something dumb I was doing with AFNetworking, or is the trailing & expected behaviour?

[nathankot]

I doubt it's expected behaviour, although a quick search in AFMotion and AFNetworking don't show any issues relating to it. I would have to guess that if this were an issue with those libraries something would have come up because it'd likely affect others as well,

are you using AFMotions request_parameters syntax? i.e

client.get("users", id: 1) do |result|
  ...
end

[matthewsinclair]

Right you are. I was defaulting a params parameter to {} which was going thru to AFNetworking. Fixed now. Thanks again!