Since today (or yesterday) the Google Place Autocomplete web service (https://developers.google.com/places/web-service/autocomplete) is returning a wrong place id (place_id). Does anyone know how to get the right place id from the Autocomplete API?
For example, the place id for New York City is ChIJOwg_06VPwokRYv534QaPC8g (according to the Place Details API), but the Autocomplete API returns ChIJOwg_06VPwokRYv534QaPC8iaBilOZXcgWW9yayBDaXR5LCBOZXcgWW9yaywgVmVyZW5pZ2RlIFN0YXRlbg as place_id. The beginning of the string is almost the same, except for the last character of the 'right' place id (g).
Is this a bug or is Google changing their place ids? Unfortunately I can't find anything related to this problem.
Some place ids from the Place Autocomplete API have been altered due to a recent issue: https://code.google.com/p/gmaps-api-issues/issues/detail?id=11107. The longer place ids should be accepted by all Maps APIs (but see the caveat in https://code.google.com/p/gmaps-api-issues/issues/detail?id=11107#c30).
Unfortunately, this will be around for some time. A way to get the "short" place id corresponding to a long one is to issue a Place Details call with the long place id (the returned result will have a short place id).
Related
We are facing a strange issue with the Look-back API.
We have created a Custom field initially as xyz, back end name c_xyz for the features.
After few days we renamed the Custom attribute to abc which in-turn changed the back-end name to c_abc, which was an expected behavior.
However , the Lookback API still gives the old field name c_xyz in the result set of that object till we actually make an update via UI/API on the abc(c_abc) attribute. Is there any way we can workaround this, apart from updating the particular value.
Briefly, no. Responding to field name changes in this way would be a big performance hit.
I am using soundcloud API for a project but the problem is I get remix of the original songs or cover version, its okay if I get remix and cover version but is there any mechanism that the original one comes as first song in the search result ? I tried searching on Google and read the API documentation but found nothing in this context.
The track object in soundcloud's API actually has the track_type property which has possible values of 'original' and 'remix' among other things. Sadly like most valueable metadata the track object has, content providers neglect to fill the field. So unless content providers start putting more effort into filling in the metadata fields the only option you have is giving songs priority based on words in the title or tags.
I need to use themoviedb.org for one of the apps I am working on. For using the API, I need an API key. How do I get an API key on themoviedb.org?
I found this in the forum:
You can request an API key by clicking on the "API" link from within your account page on the left hand sidebar. See here
In terms of making things faster for people, the URL for application is here these days (Under Account>Settings>API as previously mentioned): https://www.themoviedb.org/settings/api
You'll want to start with a Developer key as wait time for a Developer key is zero (immediate). A commercial key, as far as I understand it, is only appropriate once the app is developed and running. Turnaround for a commercial API key is about 3 days-ish though obviously could vary.
Once you have a key, inside the doco pages there's a "Try It Out" tab which lets you do calls. The normal code flow (for getting movie details) would be something like:
Get Configuration (needed for image paths, should be cached)
Search Movies (returns a list, find the numeric id for the one you want in the list returned). Be aware there might be duplicates returned - you can use the year of release, title and language to find the one you want.
Get Movie Details with the movie numeric ID, with "append_to_response" of "credits,images,trailers" so that actors, writers, directors, and trailers (aka videos) are returned.
Check doco for how to find the actual image paths, using configuration values fetched above. It's generally considered courteous to copy the images you want to use to your own server rather than serving them from TMDB's server.
THE SITUATION
I've been tooling around in the Etsy sandbox API trying to figure out a solution for a client who wants to show the default image and title to all their Etsy listings. Upon clicking, they want it to direct them off the website and onto that Esty listing's page.
Now, figuring out how to get the name and url of all their listings was easy and can be done in one public API call:
http://openapi.etsy.com/v2/shops/:shop_id/listings/active?method=GET&api_key=:api_key
This call will not only return the name of the listing and the url of listing, but also a multitude of other information on that particular item. I suppose I should limit my call to just getting the fields I need, but for sake of example, I digress...
What surprises me most is that what is not included in that gigantic array of information is something I'd expect to find in there: the images associated with the listing or at least the main image. There is however a separate API call I can make to get the images for a single listing, but that would require getting the listing_id and making a separate API call for each item. This now turns what I would expect to be one (or hell, even two) calls to the Etsy API, into 1 plus however many items you return. Granted if you have 100 items you're selling in a shop, that's 101 API calls in just a few seconds! Call me crazy, but I feel there's got to be a better way to do this than what I've found.
THE QUESTION
What is the easiest way to make an Etsy API call to return all the images (or even the main image) for all the listings in a shop?
I ended up using the following code to include everything I needed into one API call:
http://openapi.etsy.com/v2/shops/:shop_id/listings/active?method=GET&api_key=:api_key&fields=title,url&limit=100&includes=MainImage
This way I defined my fields so I don't have unnecessary information, but I also set a limit on the results and used includes=MainImage as a query string. This was to the suggestion of a member of the Etsy developer community.
Let's say user A follows user B, and B follows A. I want to know the exact date A started following B and viceversa.
Is this information stored on twitter? Can I retrieve it using the API?
To clear out: The point of this question is finding a way to know who followed who first.
(I'm assuming both A and B deleted the notification e-mails)
No Ignacio, you can't. You just can know who follows who but not the date the follow started.
Looking at the API, there's is no way, there are two calls to get the followers:
User Methods/statuses/followers
and
Social Graph Methods/followers/ids
Neither of them returns dates or even a serial that would let you see who started following first. Really, there's no indication that twitter is internally storing this information, neither in the API nor Twitter's web interface.
This is a very old question, but perhaps some might be interested to know that while you cannot get the date at which someone started following, you can at least infer an "earliest possible following date" from the fact that the list of followers is ordered according to date, and the fact that follower objects come with a created_at timestamp.
Here's a Python function for calculating an "earliest possible following date": https://github.com/BernhardClemm/twitter-follow-dates
Of course Twitter stores it, because Twitter sorts followers and following lists by the date ;)
It is possible to do this, but impractical. When you call the followers API you can page the results. Each returned object contains next_cursor and prev_cursor items. These refer to the first and last records in the next and previous pages. These values are time based and can be used to calculate the time that the respective users followed you.
It follows that, if you set the page size to 1, you can walk through the list of follower IDs one at a time and the next_cursor value will allow you to derive the follow time for the next record.
This is reasonably simple to implement, however, in practice, you'll very quickly hit Twitter's API rate limit.