Here are some example (setting italy as country):
http://api.deezer.com/2.0/track/2566127 says the track is not readable, but I can play it both from deezer.com and from an API app, the same for http://api.deezer.com/2.0/track/7960580
http://api.deezer.com/2.0/track/3259613 says the track is not readable, it is actually not existent (and usually for not existent track the API return error)
Some other times a track (which used to exist) results as not existent (e.g. http://api.deezer.com/2.0/track/17737916 Beatles - Till There Was You) both from API and deezer.com player (http://www.deezer.com/it/track/17737916) BUT if I search the song using the tile from deezer.com I can see that the track is available with a new id (APIs don't give me the "alternative" id, though).
Am I doing something wrong or the APIs responses are sometime just nor reliable?
Tracks in the Deezer API have now an "alternative" field as well as "available_countries" to deal with those country availability issues. You can check it in the API Explorer.
This is however not working for deprecated track ids, because queries on unexisting tracks will just result in a DataException. You could use ISRC codes to work around that, that we now provide as well. Hope this helps.
Related
This is more of a general programming question.
I'm trying to create an app, think of it as a Yelp clone. I have most of it working but I'm missing one important feature. The data of the places around me. For now I'm only focused on food, so I'd like it if I search something like "Pizza", it'd show me all the pizza joints near me.
I was originally planning to use Google Places API. However if you havent heard, they're changing their pricing and lowering the free tier and upping the cost by a huge margin.
There's also the problem of saving the data. One workaround I saw a user suggest was to just keep using Google's API, but every time you make the query, store the data in your own DB as well (I only need address and name and latitude and longitude) so eventually, you'd have what you need in a sense. However I also want to have something like a simple rating system for each place like Yelp, but Google (and all other places like MapBox, Here Maps, etc) states something along the lines of "info from their API should not be stored or cached for more than 24hrs" but it's very broad and not specific.
So what I was planning to do was, call the Google API, grab the 3 info I need (Address, Name, Lat/Lng), add more fields to store the rating, likes, whatever else the user will add. Then store it in my database, but that doesn't seem like a solution now.
So does anyone have any ideas or advice? Or know of a service where I can get the details of all the food places? And if possible, can anyone confirm that storing the Name, Address, Lat&Lng is a violation of their policy since in my eyes, it's public data, but something like the rating that Google provides, or the pictures that Google provides, now that's Google property.
For obtaining places you can use OpenStreetMap, e.g. using Overpass API. Since larger traffic can be expected you should run your own database(s) instead of using the public APIs.
However OSM doesn't contain ratings. So you have to combine this data with some other publicly available rating system.
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.
I'm building my first REST API (at least trying) for a personal project.
In this project there are resources called players which hold can be in a team. According to REST API design rulebook a resource should be made either to be a document or a store and one should keeps these roles as segregated as possible.
Yet I would like to append some metadata to the team resource, eg the date the team was founded. Is it okay then for GET /teams/atlanta to return this metadata (making it a document) alongside the list of players in the team (making it a store).
Is this a good idea? If so why? If not why not and how to solve this better?
I know there are no rules to developing a REST API, but there are good practices and I would like to adhere to those. Please also not that this is really my first REST API so pardon my ignorance if there is any.
I would recommend having GET /teams/atlanta return just the information about the team, such as the founding date that you mention, and then having GET /teams/atlanta/players return the list of players for that team. These distinctions become more important when you are presenting an API that uses HTTP methods other than GET.
For example, if you wanted to add a player to a team - this would be a lot easier if you could just POST a player object to /teams/atlanta/players than if you had to PUT the whole team object to /teams/atlanta every time you wanted to add one individual player.
If your API only allows retrieval of data, and if it is for a specific client application, there is an argument for combining all the team data into one object to save the client having to make additional requests for the data, but bear in mind that it is less flexible.
Your application may want to display a list of teams by calling GET /teams but you probably wouldn't want all of the player information included in each object in the list as this is quite a lot of data, but if GET /teams/atlanta returns player information then it would be inconsistent not to include it in the list version too.
I would personally favour splitting up the resources as I've suggested, and live with the fact the client may need to make an extra request or two.
Can someone explain to me in, in REST terms, Twitter's design decision with the parameter placement in these two calls? It seems that the :id placement is inconsistent and arbitrary (although clearly this was deliberate).
GET statuses/:id/retweeted_by
Show user objects of up to 100 members who retweeted the status.
GET statuses/retweets/:id
Returns up to 100 of the first retweets of a given tweet.
There are other similar examples throughout their API (https://dev.twitter.com/docs/api), so I'm definitely missing something.
Thanks!
Just making guesses here
Someone at Twitter once pointed out that the Twitter API runs on several servlets. I can only assume that this was related - it's easier to map /retweets/* than to map every single combination.
Update: I think that the history of the API itself can also be relevant. Twitter's API hasn't really changed much over the past years, and if it did change then it would be because new features would be added. An endpoint like GET statuses/show/:id is old, while GET statuses/retweets/:id is newer. If Twitter at some point decided to change naming conventions, they couldn't just rename the old ones, since it would break applications.
Another theory of mine is that GET statuses/retweets/:id actually doesn't refer to the Tweet :id itself, but is about the tweets that were based on it. GET statuses/:id/retweeted_by is directly related to the tweet itself, by returning users and not other statuses.
I too am often puzzled by the naming consistency. I'm sure they have their reasons though.
I ended up checking with a friend at Twitter, who says:
"I just talked with the guy who originally wrote those two API
endpoints, and he doesn't remember why. To answer your question,
though, there probably isn't a good RESTful reason for that design."