I'm looking at the Mandrill API documentation e.g. https://mandrillapp.com/api/docs/messages.JSON.html#method=info. In the JSON response there may be seomthing like the following
{
"ts": 1365190001,
"url": "http://www.example.com",
"ip": "55.55.55.55",
"location": "Georgia, US",
"ua": "Linux/Ubuntu/Chrome/Chrome 28.0.1500.53"
}
Is there are way to know how large the String's may be for these attributes? i.e. how many characters might be returned for "ua" or "url" etc... I'm asking as I need to capture and store some of this data in Oracle, but I don't want to LOB everything!
Related
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.
I am using survey monkey v3 API's to send survey emails. While sending a survey email from one collector, I am sending two different survey messages for the same recipient. However, while collecting the survey responses from survey monkey using the api "/surveys/{id}/responses/bulk", I couldn't find the messageID in it. So I how can I find which response belong to which message of the collector then? Is there a different API that I have to use?
What's the use case for tracking the specific message? You have the recipient_id, and first/last/email fields.
You can get recipient details at /collectors/{collector_id}/recipients/{recipient_id}. There's no way (as far as I can tell) to query for this other than searching your messages with /collectors/{collector_id}/messages/{message_id}/recipients
Generally speaking, when you add recipients to a message, they are shared with the collector. Which specific message was responded to is not really tracked, the tracking ID is the recipient_id with respect to the collector.
If you are interested in message stats (ex. which message gets a better response rate) you can use the message stats endpoint.
With regards to having a different message for say different products, unfortunately the message ID is not tied to a response, but two options are:
1) Use a different collector for each product (not ideal if there is a lot)
2) Use extra fields on the recipient (see example):
Example:
POST /v3/collectors/<collector_id>/messages/<message_id1>/recipients
{
"first_name": "Test",
"last_name": "Tester",
"email": "test#example.com",
"extra_fields": {
"product": "shoes"
}
}
POST /v3/collectors/<collector_id>/messages/<message_id2>/recipients
{
"first_name": "Test",
"last_name": "Tester",
"email": "test#example.com",
"extra_fields": {
"product": "shirts"
}
}
Then when you fetch the responses, you'll get that information in metadata, example:
{
"id": "<response_id>",
"recipient_id": "<recipient_id>",
"collector_id": "<collector_id>",
...
"metadata": {
"contact": {
"product": {
"type": "string",
"value": "shoes"
},
"email": {
"type": "string",
"value": "test#example.com"
}
}
}
}
One thing to watch out for is that the extra fields from the contact do not currently show up in the /responses/bulk endpoint, only individual responses/<id> endpoint. Also with extra fields you can't filter responses where product=shoes or whatnot. Those are some limitations with the current API - but hopefully it can at least be helpful for now.
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
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.
I'm using the Google Contacts API to get back formatted JSON, hopefully containing ALL of a user's contacts' email addresses. I use this information to search my database for the user's friends.
Neither of these results occur.
Here's the URI that's called (broken up by paramater for slightly better readability:
http://www-opensocial.googleusercontent.com/api/people/#me/#all/?
filterby=emails&max_results=1000
&oauth_consumer_key=XXXXXXX
&oauth_nonce=h7ZEI
&oauth_signature=6U2ywoPRFu8iJdQhjMRk%2FZlf%2FBg%3D
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1283979209
&oauth_token=1%2Fwv9OYV4LuffVLv6OqlFJLOtTlBo5sYYQkHbZznlLrNk
&oauth_version=1.0
&orderby=starttime
Here's some truncated and anonymized JSON I have returned.
{
"startIndex": 0,
"totalResults": 615,
"entry": [
{
"id": "XXXXXXXXXXXXXXXXXXX",
"name": {
"formatted": "XXXXX XXXXXX",
"familyName": "XXXXXXX",
"givenName": "XXXXXX"
},
"displayName": "XXXXX XXXXXX"
},
],
"itemsPerPage": 20
}
Any thoughts on what's going wrong here would be great.
Hate to answer my own question so soon, but I was using the wrong initial scope. I was using Google's Open Social feed rather than the Google Contacts feed.