I am using MusicBrainz to get a track's meta data. I want to get the track's album's mbid. I am doing the following lookup using ISRC code.
https://musicbrainz.org/ws/2/isrc/USRC11600201?fmt=json
But in response I don't get any metadata related to the album of the track. I get the following response:
{
"isrc": "USRC11600201",
"recordings": [
{
"disambiguation": "single remix",
"title": "Cheap Thrills",
"id": "92e27a47-3546-4bc2-a9f7-b19e43d7a531",
"length": 223000,
"video": false
},
{
"length": 218540,
"video": false,
"title": "Cheap Thrills",
"disambiguation": "",
"id": "5845e975-33b4-4b0d-8e74-8f57d128b3d1"
}
]
}
I have tried various combinations of the "inc" sub query parameter as well but nothing works. Please help me out. I am really stuck at this.
Using inc=releases in the URL parameters should be enough to get you the information that you want. However, it seems like there's a bug with MusicBrainz's JSON web service (which is still officially in beta), as you can see in the difference between the XML and JSON end points' output:
https://musicbrainz.org/ws/2/isrc/USRC11600201?inc=releases&fmt=json (JSON) vs. https://musicbrainz.org/ws/2/isrc/USRC11600201?inc=releases (XML).
One obvious solution/work-around here would be to switch to using the more mature XML endpoint. If that is not an option, you can use the Recording MBIDs given in the JSON output to look up releases associated with those Recordings, e.g., https://musicbrainz.org/ws/2/recording/5845e975-33b4-4b0d-8e74-8f57d128b3d1?inc=releases&fmt=json (note that inc=releases is also needed here to get the information about the releases, and it actually works when looking up recordings).
So to get the details of the album of a track when I have the ISRC of the track, we need to do the following get request:
https://musicbrainz.org/ws/2/isrc/GBUM71604605?inc=releases
It will give a response in xml. The xml api is more stable click for more details on this
As I need the response in json, we can use a library like xml to json and vice-versa library
As much as I have seen the xml response from the MusicBrainz api is more accurate and gives a lot of information.
Related
I have been trying to fetch all videos from a playlist using YouTube Data API, which worked like a char; next, I wanted to try and filter videos based on languages, so I wanted to try to include the "localizations" part. However, whenever I do, I get a 400 response stating that "localizations" is "unkownPart". From what I could see in the documentation, I should have my GET request structured properly:
`https://youtube.googleapis.com/youtube/v3/playlistItems?part=localizations&part=snippet&maxResults=${limit}&playlistId=${playlistId}&key=${apiKey}`
Error message in postman:
{
"error": {
"code": 400,
"message": "'localizations'",
"errors": [
{
"message": "'localizations'",
"domain": "youtube.part",
"reason": "unknownPart",
"location": "part",
"locationType": "parameter"
}
]
}
}
"localizations" is a direct copy from the documentation. The GET request works fine if I remove it so I'm confident that the problem is either the order or my parameters, or the combinations of parameters in use (though I couldn't find anything about incompatible parameters in the documentation).
Parameters order goes as follows:
localizations
snippet
playlistId
key
EDIT: link to the documentation: https://developers.google.com/youtube/v3/docs/playlists/list
After sending the Issue Report it was discovered that I had been using the wrong API endpoint. Somehow (I can't remember why) I was using the "playlistItem" endpoint which doesn't support "localizations", and needed to shift to using the "playlists" endpoint instead.
Furthermore when using a combination of both "snippet" and "localization", they should be within the same parameter but comma-separated, however, Postman doesn't auto-convert the commas in the parameters to "%2C" and therefore would cause further trouble understanding the requests. Fixing these 2 steps, it now works as intended.
We are integrating our product with MS OneDrive. Our users will connect their MS accounts and choose a folder that they want us to pull files from. Our system only supports certain file types so we have to get the mimetype information AND the file ID after making a request. But we can't find a request that brings back both pieces of information so we can determine if we should pull a file or not.
This is close, but it doesn't give us the mimetype information.
https://learn.microsoft.com/en-us/onedrive/developer/rest-api/api/drive_recent?view=odsp-graph-online
Anyone have any ideas?
The get method lets you retrieve all kinds of information about a file: https://learn.microsoft.com/en-us/onedrive/developer/rest-api/api/driveitem_get?view=odsp-graph-online
It returns a driveItem object, that has a file property. And that file property has a mimeType property. See here https://learn.microsoft.com/en-us/onedrive/developer/rest-api/resources/driveitem?view=odsp-graph-online and here https://learn.microsoft.com/en-us/onedrive/developer/rest-api/resources/file?view=odsp-graph-online.
Unfortunately that means, that you will need more than one request to get the information you want.
If filtering by filename suffix is good enough for you, you can query OneDrive like this:
POST /search/query
Content-Type: application/json
{
"requests": [
{
"entityTypes": [
"driveItem"
],
"query": {
"queryString": "filetype:docx OR filetype:doc"
}
}
]
}
Documentation: https://learn.microsoft.com/en-us/graph/search-concept-files#example-5-use-filters-in-search-queries
How do I connect my database to API.AI
Making every sentence into INTENT and creating entities for each doesn't seem to be a good idea? So what is the best possible way to go about?
As far as I know it is not possible yet, but you can switch to row mode and past your entities inCVS or JSON format OR import a JSON/CSV file containing all your entities.
The file should look like below (JSON format):
[
{
"value": "val1",
"synonyms": [
"syn1",
"syn2"
]
},
{
"value": "val2",
"synonyms": [
"syn21",
"syn22"
]
},
]
So you can image of writing a small job that reads entities from you DB and make a JSON/CSV file according the wanted format.
Once the job done, this process may dramatically facilitate the creation of your entities on api.ai.
If you use a webhook for an intent, you can pass params to your endpoint where you can do all the queries to your db
I did a demo where I was querying news (cheating as I was getting it from the web, but I could plug a DB).
The was getting requests such as:
"What are the latest news about France"
latest and France would be params that I send through to the webhook endpoint.
You would get the following JSON sent your endpoint by API.AI
"result": {
"source": "agent",
"resolvedQuery": "latest news about France",
"action": "show.news",
"actionIncomplete": false,
"parameters": {
"adjective": "latest",
"subject": "France"
}
Then you can query all the news for France and order them by latest
In my understanding the idea is to create entities that are "placeholders" for the values you need to query.
Then you teach the AI with few examples by tagging in the request what did the person ask. Let say someone asks:
"what is the oldest news about France?"
The AI may not know what is oldest thus you tell it is is an adjective and from now on you can get oldest as a param
When using the YouTube API v3 to query a channel's branding settings, why are they returned for queries by channel ID, but not for queries by username? The API doesn't return branding settings for channel list queries by username.
If you query for a channel's branding settings by channel ID (e.g., id=UC8-Th83bH_thdKZDJCrn88g), you are returned a complete set of branding settings:
Google API Explorer: https://developers.google.com/youtube/v3/docs/channels/list
Request
GET https://www.googleapis.com/youtube/v3/channels?part=brandingSettings&id=UC8-Th83bH_thdKZDJCrn88g&key={YOUR_API_KEY}
Response
{
// ... snip ...
"items": [
{
"kind": "youtube#channel",
"etag": "\"...\"",
"id": "UC8-Th83bH_thdKZDJCrn88g",
"brandingSettings": {
"channel": {
"title": "The Tonight Show Starring Jimmy Fallon",
"description": "Watch The Tonight Show Starring Jimmy Fallon Weeknights 11:35/10:35c\n\nThe Tonight Show Starring Jimmy Fallon features hilarious highlights from the show including: comedy sketches, music parodies, celebrity interviews, ridiculous games, and, of course, Jimmy's Thank You Notes and hashtags! You'll also find behind the scenes videos and other great web exclusives.",
// all the branding settings are here
}
}
}]
}
If, on the other hand, you send a channel list query for a username (e.g., forUsername=latenight), you get no branding settings at all. The branding settings aren't returned or populated.
Request
GET https://www.googleapis.com/youtube/v3/channels?part=brandingSettings&forUsername=latenight&key={YOUR_API_KEY}
Response
{
// ... snip ...
"items": [
{
"kind": "youtube#channel",
"etag": "\"...\"",
"id": "UC8-Th83bH_thdKZDJCrn88g"
}]
}
I may be wrong, but I believe that, in v3 of the APIs, Channel IDs are the only way to get a full response, as the concept of a "username" doesn't really exist in the same way anymore. That is, newly created YouTube channels are linked to a G+ profile and can have a display name, but there isn't really any YouTube username anymore associated with such a channel.
Because usernames used to exist, though, and many channels are still known by them, the "forUsername" parameter is there to provide you the associated channelID and then issue the request for the branding settings with that.
Now, having said that, it's clear that the language on the API explorer page doesn't reflect that, and perhaps therein lies the problem; I'm taking my inferences from this documentation:
https://developers.google.com/youtube/v3/guides/working_with_channel_ids#v3
and from this bug report:
https://code.google.com/p/gdata-issues/issues/detail?id=4821&q=forUsername&colspec=API%20ID%20Type%20Status%20Priority%20Stars%20Summary
But it's always possible, too, that I'm reading incorrectly and you're actually seeing a new bug. The only way to know for sure would be to file it (or perhaps someone on the team could comment here)?
I'm currently working on iOS Application with RestKit 0.20 to access data from Tastypie API.
And I am trying to get feeds data from URL like this
/api/v2/feed/?format=json
Then I will get array of feeds as below.
{
"meta": {
"limit": 20,
"next": null,
"offset": 0,
"previous": null,
"total_count": 2
},
"objects": [
{
"id": 1,
"info": "This is my first post",
"pub_date": "2013-02-03T15:59:33.311000",
"user": "/api/v2/user/1/",
"resource_uri": "/api/v2/feed/1/"
},
{
"id": 2,
"info": "second post, yeah",
"pub_date": "2013-02-03T16:00:09.350000",
"user": "/api/v2/user/1/",
"resource_uri": "/api/v2/feed/2/"
}
]
}
if I want to fetch more data about user which Tastypie send it as url like a foreign key "user": "/api/v2/user/1/", do I have to nested call objectRequestOperation.
I'm confusing because I'm using block to callback when data is successful loaded. So is there any better way than requesting user data again for each feed after requesting feed complete.
Thank you very much :)
You have to define in the Feed resource :
user = fields.ToOneField(UserResource, full=True)
More info in the tastypie doc http://django-tastypie.readthedocs.org/en/latest/resources.html
Why Resource URIs?
Resource URIs play a heavy role in how Tastypie delivers data. This can seem very different from other solutions which simply inline related data. Though Tastypie can inline data like that (using full=True on the field with the relation), the default is to provide URIs.
URIs are useful because it results in smaller payloads, letting you fetch only the data that is important to you. You can imagine an instance where an object has thousands of related items that you may not be interested in.
URIs are also very cache-able, because the data at each endpoint is less likely to frequently change.
And URIs encourage proper use of each endpoint to display the data that endpoint covers.
Ideology aside, you should use whatever suits you. If you prefer fewer requests & fewer endpoints, use of full=True is available, but be aware of the consequences of each approach.