In trying to get a list of foursquare venues by id, I ended up using the multi endpoint.
However, the venues returned do not have a distance value from my current lat long
So, as an example I can use the venue endpoint
https://api.foursquare.com/v2/venues/43f9b9aaf964a520d12f1fe3?ll=47.62330382444445,-122.33604573666668
This will return a venue which has a distance value
However, trying to do the same using the multi endpoint
https://api.foursquare.com/v2/multi?requests=/venues/43f9b9aaf964a520d12f1fe3,/venues/40a55d80f964a52020f31ee3&ll=47.62330382444445,-122.33604573666668
This does not return a distance value
Any idea how to use the lat long parameter on a multi request?
I couldn't find much documentation on this
You need to pass the "ll" parameter as part of each of the requests listed out in "requests". Currently, the "ll" parameter is being interpreted as an argument to the "multi" endpoint, when you actually want it to be a parameter on each of the two "venues" requests.
You should URL encode the both of the full requests (including the ll parameter) and set that as the value of the "requests" parameter.
Related
I am trying to use the api GET /restapi/v2.1/accounts/{accountId}/envelopes with the following parameters;
from_date
to_date
start_position
order (asc)
order_by ('created')
Example api call
{{baseURL}}/restapi/v2/accounts/{{docusign-accountId}}/envelopes?from_date=2019-09-01T00:00:07.2430000Z&to_date=2020-03-25T01:01:07.2430000Z&start_position=0&count=1000&order=asc&order_by=created
Here I was expecting the response to be all envelopes that had status changes between the time range [from_data, to_date] ordered by their created time in ascending order.
However, I don't see the order_by field has any effect on the response. The envelopes that I am receiving are still ordered by statusChangedDateTime value (ascending order).
But, if I include another parameter to the api call
from_to_status = 'created'
The response includes envelopes in the ascending order of their created time.
Please let me know if this is actually a bug and order_by field is not being respected currently, Or it's a limitation that order_by = created can only work with from_to_status = created. Or please let me know in case I am doing something wrong in using it properly.
You started by talking about 2.1 and then used 2.0.
Your URL should be modified to use the 2.1 version of the API:
{{baseURL}}/restapi/v2.1/accounts/{{docusign-accountId}}/envelopes?from_date=2019-09-01T00:00:07.2430000Z&to_date=2020-03-25T01:01:07.2430000Z&start_position=0&count=1000&order=asc&order_by=created
What's the difference between using : and ? in a URL? For example /products/:id and /products?id=1? I am trying to get the values from the URL like this Product.findById (req.params.id) but I was wondering which one is most suitable. I know using : do I have to use req.params and ? req.query but I don't understand the difference between them, are they the same?
in my point of view, it is totally different if you are using RESTFUL API pattern
/products/:id called path parameters
The path parameters determine the resource you’re requesting for. Think of it like an automatic answering machine that asks you to press 1 for service, press 2 for another service, 3 for yet another service and so on.
Path parameters are part of the endpoint itself and are not optional
but query parameters
Technically, query parameters are not part of the REST architecture, and they used to help you completely understand how to read and use API’s Query parameters give you the option to modify your request with key-value pairs.
Having your parameters in the query is conceptually optional to the router, query parameters are more of properties and descriptions of the request itself, like when saying GET /users?sort=asc, in this case, the sort attribute was more of a description to the request and the request could complete the fetch without it, that might not always be the case, but a query parameter still describes its request even if it was mandatory.
On the other hand, URL parameters are part of the request itself, the URL without the parameter doesn't make sense, like GET /users/:userID, in this case, not supplying userID will supply unexpected data (A list of users for example) if it didn't break the router completely. URL parameters play part in defining the request rather than just describing it, and they can't be optional.
my goal is simply list all the places within 20 KM from point A, Im using Google Maps API to help me with this
I use node.js/Express + mongoose for the backend part.
For example, If i live at Point A, and if I open up my phone, it would show all the list of places nearby my location which is Point A within 20 KM
How would I achieve this in the backend?
What are the condition should I pass to mongoose to find the list of places, or my approach is wrong?
Place.find({}, function(err, places) {
res.json(places);
});
Use Place Search - Nearby Search request for places within a specified area. You can refine your search request by supplying keywords or specifying the type of place you are searching for.
Here's a sample Nearby Search request:
https://maps.googleapis.com/maps/api/place/nearbysearch/output?parameters
Include rankby parameter to specifiy the order in which results are listed. Possible values are prominence, distance and location.
Here's a related SO ticket:
Google Nearby places search
An alternative is to use Places API Web services.
You have 2 aptions to search 1) Nearby search returns complete information of each place but it returns up to 20 results on each query and if more places available, it returns a "next page" token.
url="https://maps.googleapis.com/maps/api/place/nearbysearch/json?location="+lat+","+long+"&radius=" +radius+"&types=" + types + "&key=<PUT_YOUR_API_KEY_HERE>";
lat and long are your center coordinates. radius is measured in meters and is a value up to 50000. types is the type of Place you are searching according to this listing: https://developers.google.com/places/supported_types . Example: "atm"
2) Radar search that returns a reduced set of information of each place but it returns up to 200 on each query
url="https://maps.googleapis.com/maps/api/place/radarsearch/json?location="+lat+","+long+"&radius=" +radius+"&types=" + types + "&key=<PUT_YOUR_API_KEY_HERE>";
lat and long are your center coordinates. radius is measured in meters and is a value up to 50000. types is the type of Place you are searching according to this listing: https://developers.google.com/places/supported_types . Example: "atm"
You have more options to search, keyword & name appart from type. Keep in mind that you must specify at least one of them.
You can have your results on xml or json format.
Full definition of nearby and radar search is here: https://developers.google.com/places/web-service/search
I take an string from user and must search its places in whole of world.
I want to use foursquare venues api.
but in that endpoint I must set search ranges by (ll and radius) or (sw and ne) or (near and radius).
now how search places for an string in whole of world ?
You can set the intent parameter to "global":
intent=global
See Venue Search Parameters:
global
Finds the most globally relevant venues for the search, independent of location.
Ignores all parameters other than query and limit.
For example:
https://api.foursquare.com/v2/venues/search?intent=global&query=apple+store&oauth_token=(YOUR_TOKEN)&v=20150721
If you use the global value, all other parameters except query and limit are ignored.
I'm been searching around, and I dont understand why it is, that if I create a query for the projection and I say I want to filter a field of the returned Content Type by a Field of the current user, that no rows are returned.
If I replace the token with a hard coded value, it does work. I'm just missing some important understanding about why the token has no value.
This is not how it works. You may use tokens in projections as long as they are not expected to vary per record. Tokens can be used if they are external data (querystring parameters, etc.) To make your scenario work, you'll have to build your own filter.