Multiple waypoints in Google Maps API Web Services - objective-c

I'm using the Directions API for this. The API states the parameter waypoints should be used to pass locations or addresses through which needs to be navigated. When passing one waypoint, it works perfectly:
https://maps.googleapis.com/maps/api/directions/json?origin=38.04042392261285,-95.95928934382054&destination=38.02603529451354,-95.95908408863205&mode=walking&units=metric&sensor=true&waypoints=38.03945399159401,-95.94861607401845
When passing more than one waypoint, it stops working. I don't get ANY response back from the request. Note that I separated the locations with the pipe symbol (|) as stated in the API:
https://maps.googleapis.com/maps/api/directions/json?origin=38.04042392261285,-95.95928934382054&destination=38.02603529451354,-95.95908408863205&mode=walking&units=metric&sensor=true&waypoints=38.03945399159401,-95.94861607401845|38.02603529451354,-95.94943709477245

Seems the pipe character is not being escaped, I was using this:
waypointsURL = [waypointsURL stringByAppendingString:#"|"];
Instead, use this:
waypointsURL = [waypointsURL stringByAppendingString:#"%7C"];

Related

Using a Wildcard in Postman API Call

I am trying to perform a GET API call in Postman.
One of the parameters in the query (a string) should include a wildcard, since I want to receive response which includes several optional values (for example "Demo1...", "Demo2...").
Any suggestion how this can be done?

URL Parameters for API

I am trying to connect to this API endpoint, some parameters such as roomTypes and addOns require more parameters inside them. What should the URL be like?
Here is what I am trying, unsuccessfully:
https://api.lodgify.com/v2/quote/308200/?arrival=2020-10-02&departure=2020-10-07&propertyId=308200&roomTypes=[Id=373125, People=5]&addOns=[]
See image of Documentation
The correct format of parameters are as following:
https://api.lodgify.com/v2/quote/{PropertyID}?arrival={DATE}&departure={DATE}&roomTypes[0].id={RoomID}&roomTypes[0].people={PEOPLE}
It seems like you have space (white space) between Id and People in your URL, an URL must not contain a literal space

batchGet endpoint behavior with multiple photos

I am testing the photos.batchGet endpoint.
Per the API docs, it takes two URL parameters "view" and "photoIds". When I try the photoIds parameter, the request only works with one photoId. Using multiple photoIds fails.
I tried using a delimeter between the photoIds in the string (by using a comma, pipe, and space). I also tried not using a delimeter at all. Not using a delimeter returns a response for the last photoId in the string, but not for any of the other photoIds. In short, none of my requests appear to be working. Am I doing something wrong?
Also, depending on server configuration, I think it's recommended for the URL length to be under 2,000 characters. Anything above 30 photoIds would create URLs longer than this.
That being said, maybe it would be better to make this a POST request that accepts a JSON request body? Just a thought, but think this would be better suited. A lot of our tours are above 30 scenes, and we even had a tour with 700 scenes!
The description of the batchGet function was updated. Per the documentation you should pass photoIds as a string and the URL query parameter should be photoIds=<id1>&photoIds=<id2>.

Use Google's mobile vision api to detect numbers only?

I would like to know how I can filter to detect numbers (integers) only? e.g 1,2,....,10. Currently the api detects all formats of "text".
You should do that processing on your side. Use Regex to filter out numbers from string received from Vision API:
str="Text received 123,0";
number = str.replace(/\D/g,'');
result: 123
Google vision API will detect all character, google vision does not
have separate API(which can detect only number at the point of
scanning) for only numbers till now, But after scanning the image
using google vision api we will get the text in response example
"23XA3783", so now we can replace the character we don't want.
Store the google api response in temp variable
source_str = "23XA3783"
In my case I get the required string from google api response using
js
source_str= temp["responses"][0].textAnnotations[0].description
final_output = source_str.replace(/\D/g,'');

Preventing YQL from URL encoding a key

I am wondering if it is possible to prevent YQL from URL encoding a key for a datatable?
Example:
The current guardian API works with IDs like this:
item_id = "environment/2010/oct/29/biodiversity-talks-ministers-nagoya-strategy"
The problem with these IDs is that they contain slashes (/) and these characters should not be URL encoded in the API call but instead stay as they are.
So If I now have this query
SELECT * FROM guardian.content.item WHERE item_id='environment/2010/oct/29/biodiversity-talks-ministers-nagoya-strategy'
while using the following url defintion in my datatable
<url>http://content.guardianapis.com/{item_id}</url>
then this results in this API call
http://content.guardianapis.com/environment%2F2010%2Foct%2F29%2Fbiodiversity-talks-ministers-nagoya-strategy?format=xml&order-by=newest&show-fields=all
Instead the guardian API expects the call to look like this:
http://content.guardianapis.com/environment/2010/oct/29/biodiversity-talks-ministers-nagoya-strategy?format=xml&order-by=newest&show-fields=all
So the problem is really just that the / characters gets encoded as %2F which I don't want to happen in this case.
Any ideas on how this can be achieved?
You can also check the full datatable I am using:
http://github.com/spier/yql-tables/blob/master/guardian/guardian.content.item.xml
The URI-template expansions in YQL (e.g. {item_id}) only follow the version 3 spec. With version 4 it would be possible to simply (only slightly) change the expansion to do what you want, but alas not currently with YQL.
So, a solution. You could bring a very, very basic <execute> block into play: one which adds the item_id value to the path as needed.
<execute><![CDATA[
response.object = request.path(item_id).get().response;
]]></execute>
Finally, see the diff against your table (with a few other, minor tweaks to allow the above to work).