title: Retrofit: How to specify comma-separated parameters in request?
body: <p>I'm trying to refactor my code to use Retrofit (from Volley) for some Foursquare API calls but haven't found a proper example that shows how to specify a query parameter that has 2 values separated by a comma.</p>
  
  <p>My base url is the following:</p>
  
  <pre class="lang-java prettyprint-override"><code>public static final String VENUES_BASE_URL = "https://api.foursquare.com/v2/venues";
  </code></pre>
  
  <p>The rest of my url is like this:</p>
  
  <pre class="lang-java prettyprint-override"><code>"?ll=40.7,50.2&amp;limit=50&amp;radius=25000&amp;v=20140909&amp;venuePhotos=1&amp;oauth_token=xxyyxx";
  </code></pre>
  
  <p><strong>1st implementation for my interface:</strong></p>
  
  <pre class="lang-java prettyprint-override"><code>public interface Fourquare {
      @GET("/explore?ll={p1},{p2}&amp;limit=50&amp;radius=25000&amp;v=20140905&amp;venuePhotos=1&amp;oauth_token=xxyyxx")
      Response getVenues(@Path("p1") String param1,
                     @Path("p2") String param2);
  
  }
  </code></pre>
  
  <p><strong>And then made the request like this:</strong></p>
  
  <pre class="lang-java prettyprint-override"><code>RestAdapter restAdapter = new RestAdapter.Builder()
              .setEndpoint(ConfigConstants.VENUES_BASE_URL)
              .build();
  
      Fourquare fourquare = restAdapter.create(Fourquare.class);
      Response myResponse = fourquare.getVenues("50", "75");
  </code></pre>
  
  <p>However, the above gave me the following error:</p>
  
  <pre><code>retrofit.RetrofitError: Fourquare.getVenues: URL query string "ll={p1},{p2}&amp;limit=50&amp;radius=25000&amp;v=20140905&amp;venuePhotos=1&amp;oauth_token=xxyyxx" must not have replace block.
  </code></pre>
  
  <p><strong>2nd implementation</strong> (After looking at some of the SO responses that use Query parameters. NOTE: Once I figure out the ll? parameter call I will have the token as a parameter):</p>
  
  <pre class="lang-java prettyprint-override"><code>@GET("/explore&amp;limit=50&amp;radius=25000&amp;v=20140905&amp;venuePhotos=1&amp;oauth_token=xxyyxx")
  void getVenues(@Query("ll") String ll,
                        Callback&lt;String&gt; cb);
  </code></pre>
  
  <p>With the actual call like this:</p>
  
  <pre class="lang-java prettyprint-override"><code>fourquare.getVenues("50,75", new Callback&lt;String&gt;() {
          @Override
          public void success(String s, Response response) {
              Log.d(TAG, "Successful run!");
          }
  
          @Override
          public void failure(RetrofitError error) {
              Log.d(TAG, "Failed run!");
          }
      });
  </code></pre>
  
  <p>With the above implementation the failure() method is always getting called, so there is still something wrong with my code.  Can someone please give some suggestions as to the proper way to implement this call? I'm most certain the issue is with the "ll?" parameter. </p>
  
  <p><strong>Update:</strong>
  After turning logging this is the final url I'm getting from Retrofit:
  <a href="https://api.foursquare.com/v2/venues/explore&amp;limit=50&amp;radius=25000&amp;v=20140909&amp;venuePhotos=1&amp;oauth_token=xxyyxx?ll=30.26%2C-97.74" rel="noreferrer">https://api.foursquare.com/v2/venues/explore&amp;limit=50&amp;radius=25000&amp;v=20140909&amp;venuePhotos=1&amp;oauth_token=xxyyxx?ll=30.26%2C-97.74</a></p>
  
  <p>It looks like the Foursquare server does not like the ?ll parameter at the end of the url and it must be explicitly placed right after ../v2/venues/explore as that is working fine when a place the request through the browser.</p>
  
  <p>Any solutions to get around this limitation from the API?</p>
  
  <p><strong>3rd implementation (9/17/14)</strong> With <a href="https://stackoverflow.com/users/272761/colriot">colriot</a> suggestion I was able to resolve the 400 response code I was getting with my previous implementation.  I'm still having a speed issue with GSON so looking for suggestions on how to fix that. Specifically, my Retrofit implementation is taking longer to display my results compared to Volley so I'm wondering if there is a better way to implement the callback.</p>
  
  <p><strong>Foursquare interface</strong>
  </p>
  
  <pre><code>public interface Fourquare {   
      @GET("/explore?limit=50&amp;radius=25000&amp;v=20140909&amp;venuePhotos=1&amp;oauth_token=xxyyxx")
      void getVenues(@Query("ll") String ll,
                  Callback&lt;Object&gt; cb);
  }
  </code></pre>
  
  <p><strong>RestAdapter call</strong>
  </p>
  
  <pre><code>RestAdapter restAdapter = new RestAdapter.Builder()
              .setEndpoint(ConfigConstants.VENUES_BASE_URL)
              .build();
  
      Foursquare foursquare = restAdapter.create(Foursquare.class);
  
  foursquare.getVenues("30.26,-97.74", new Callback&lt;Object&gt;() {
          @Override
          public void success(Object o, Response response) {
              Log.d(TAG, "Success!");
              // Parse response
              GsonBuilder gsonBuilder = new GsonBuilder();
              Gson gson = gsonBuilder.create();
              JsonParser parser = new JsonParser();
              String response2 = gson.toJson(o);
              JsonObject data = parser.parse(response2).getAsJsonObject();
  
              // Populate data model
              MetaResponse metaResponse = gson.fromJson(data.get("meta"), MetaResponse.class);
              VenuesExploreResponse myResponse = gson.fromJson(data.get("response"), VenuesExploreResponse.class);                
  
              // Store results from myResponse in List
          }
  
          @Override
          public void failure(RetrofitError error) {
              Log.d(TAG, "Failures!");
          }
      });
  </code></pre>
  
  <p>The current issue with the above callback implementation is that it is taking longer (about 1 second) than with Volley to parse and show the results. The GsonBuilder/Gson/JsonParser block is exactly the same as in my Volley onResponse(String response) method except for that intermediate "response2" object, so most definitely this intermediate/extra step is the bottleneck.  I'm looking for suggestions on how to better implement the Gson parsing. If this might fit better as a new/separate question I'll do so.</p>