Twitter search api with hindi characters in the query returns 403 error - twitter

I am receiving 403 error from search api when using this query:
"सार्वजनिक स्वास्थ्य जॉन्स हॉपकिन्स विश्वविद्यालय" OR "एमए एन ए
पौष्टिक सहायता उत्पाद निगम" OR "मेडिसिन्स सैंस फ्रंटियर्स"
Error I have got from Twitter's api is:
{exceptionCode=[8e13056f-6071abbc], statusCode=403, message=Missing or
invalid url parameter., code=195, retryAfter=-1,
rateLimitStatus=RateLimitStatusJSONImpl{remaining=447, limit=450,
resetTimeInSeconds=1464249586, secondsUntilReset=695}, version=4.0.1}
It is strange because if I cut any element from original query it works.
The request I send is:
https://api.twitter.com/1.1/search/tweets.json?q=%22%E0%A4%B8%E0%A4%BE%E0%A4%B0%E0%A5%8D%E0%A4%B5%E0%A4%9C%E0%A4%A8%E0%A4%BF%E0%A4%95%20%E0%A4%B8%E0%A5%8D%E0%A4%B5%E0%A4%BE%E0%A4%B8%E0%A5%8D%E0%A4%A5%E0%A5%8D%E0%A4%AF%20%E0%A4%9C%E0%A5%89%E0%A4%A8%E0%A5%8D%E0%A4%B8%20%E0%A4%B9%E0%A5%89%E0%A4%AA%E0%A4%95%E0%A4%BF%E0%A4%A8%E0%A5%8D%E0%A4%B8%20%E0%A4%B5%E0%A4%BF%E0%A4%B6%E0%A5%8D%E0%A4%B5%E0%A4%B5%E0%A4%BF%E0%A4%A6%E0%A5%8D%E0%A4%AF%E0%A4%BE%E0%A4%B2%E0%A4%AF%22%20OR%20%22%E0%A4%8F%E0%A4%AE%E0%A4%8F%20%E0%A4%8F%E0%A4%A8%20%E0%A4%8F%20%E0%A4%AA%E0%A5%8C%E0%A4%B7%E0%A5%8D%E0%A4%9F%E0%A4%BF%E0%A4%95%20%E0%A4%B8%E0%A4%B9%E0%A4%BE%E0%A4%AF%E0%A4%A4%E0%A4%BE%20%E0%A4%89%E0%A4%A4%E0%A5%8D%E0%A4%AA%E0%A4%BE%E0%A4%A6%20%E0%A4%A8%E0%A4%BF%E0%A4%97%E0%A4%AE%22%20OR%20%22%E0%A4%AE%E0%A5%87%E0%A4%A1%E0%A4%BF%E0%A4%B8%E0%A4%BF%E0%A4%A8%E0%A5%8D%E0%A4%B8%20%E0%A4%B8%E0%A5%88%E0%A4%82%E0%A4%B8%20%E0%A4%AB%E0%A5%8D%E0%A4%B0%E0%A4%82%E0%A4%9F%E0%A4%BF%E0%A4%AF%E0%A4%B0%E0%A5%8D%E0%A4%B8%22&count=100&since=2016-05-23&with_twitter_user_id=true&include_entities=true
Do you have any idea what is wrong?

You just hit a query limit, you can get similar failures with even a simple repeated A OR B query once it gets over the max length.
https://dev.twitter.com/rest/reference/get/search/tweets
q: A UTF-8, URL-encoded search query of 500 characters maximum,
including operators. Queries may additionally be limited by
complexity.
Since you want an OR, you should probably query 3 times and union the results in your code.

Related

How to receive messages in ascending by received date order in graph api

I am trying to receive email messages via Microsoft Graph API:
requestBuilder
.Delta()
.Request()
.Expand("attachments")
.GetAsync(ChildCancellationToken.Token);
but messages come in descending order by ReceivedDateTime. For example we have 15 new messages with ReceivedDateTime = n, where n represents date time.
In first part will come:
[15,14,13,12,11,10,9,8,7,6 (deltaHash="someValue")]
in second:
[5,4,3,2,1 (deltaHash=NULL)]
So, the oldest email will come the latest (LIFO, not FIFO).
But I expect to get:
[1,2,3,4,5,6,7,8,9,10 (deltaHash="someValue")]
[11,23,13,14,15 (deltaHash=NULL)]
What I tried: I tried OrderBy(string value).
For these two I get exceptions:
.OrderBy("ReceivedDateTime asc")
.OrderBy("ReceivedDateTime")
This is working fine:
.OrderBy("ReceivedDateTime desc")
but this is the same as default behavior and I think this is a bug actually. So there is no way to sort emails in ASC order.
How to solve on first look very simple and common requirement?
Looks like this is a known issue as specified in the documentation.
The only supported $orderby expression is
$orderby=receivedDateTime+desc. If you do not include an $orderby
expression, the return order is not guaranteed.
So for now you need to sort them on your end by writing your own code.
I can confirm that .OrderBy("ReceivedDateTime asc") is now working as of the version of the microsoft-graph API I am using which is 5.36.0

YQL error into pressure when use u=c

good morning,
I starting to use a YQL for extract a weather condition for my town.
I live in Italy and set the query with u=c parameter, but in this case the pressure value is wrong.
If I request without u=c the query return:
atmosphere
pressure "1006.0"
but if I send a query with u=c return is:
atmosphere
pressure "34067.08"
my query is:
https://query.yahooapis.com/v1/public/yql?q=select * from weather.forecast where woeid in (select woeid from geo.places(1) where text="codogno,it") and u=c&format=json
I think Yahoo got it wrong. So if you requested u=c then it returns millibars but it is not expected value you must convert it to inch then you got the real millibars.
then if you requested u=f then it returns in but it is not as expected value it is a millibars so you must again convert it to an in.
Maybe we should consider a new provider.

Jira Rest Api JQL isnt working using &

Iam using the Jira Rest Api to read data from our Jira-System. In most cases this works fine but i have a problem if & is in query.
I try following query:
http://jira-test.meinServer.de/rest/api/2/search?jql=labels="F&E"
which produces this error message:
"Fehler in der JQL-Abfrage: Die Zeichenfolge mit Anführungszeichen 'F' wurde nicht abgeschlossen. (Zeile 1, Zeichen 8)"
in englisch:
"Error in JQL-Syntax: The string with 'F' isn't closed. (line 1, char 8)"
I found that & is the problem. But i can't find some workaround or documentation how to escape this.
Someone got a solution for this?
You didn't encode your query string properly. Try: http://jira-test.meinServer.de/rest/api/2/search?jql=labels%3D%22F%26E%22
Reference
The part of an URI caught between ? and # characters is called the query string (the part after # is called fragment). Often the query is a sequence of key–value pairs (laid out as {key}={value}) separated with the & character.
If you analyze the URL you provided and split it by & you'll see that in fact you are passing two parameters in your query string:
parameter jql with a value of labels="F
parameter E" with no value
The second parameter is ignored as this particular REST endpoint doesn't expect it. As you can now clearly see you are passing a malformed JQL in your URL. It's because you want to include a special character in your JQL query.
To make it possible you have to properly encode your JQL. This is a common problem and most of the platforms provide tools to do that. Here are examples for JavaScript, C# and Java.
Click here to learn more about the query strings.

Difference between "{single_word"} and {single_word} searches on google docs

For some queries with documentlist api (and also within UI) I get different results for this queries:
1. "single_word"
2. single_word
For example for this:
"mody" - I receive 69 results
mody - I receive >200 results (many of them don't contains this word)
(This happens also for combination of words that contains this word. For example:
**"mody" company** and **mody company** returns different results)
Which is the difference between this searches? And how it is recommanded to search for best exact matches results? I don't want to receive results that contains only mod (for example) words.
"mody" matches tokens exactly with only the characters m-o-d-y, and whitespace on either side. It only matches mody.
mody matches tokens containing the characters m-o-d-y. It would match mymody, mody, asdfmody, modyasdf, etc.

YQL sample query returns max 260 results

I am following YQL sample query
select * from local.search(500) where query="sushi" and location="san francisco, ca"
but I get 260 max count instead of 500. I tried also to use limit 500 after 'where' and different keywords, always get maximum 260 results. How do you increase it?
The underlying API that the local.search table uses (Yahoo! Local Search Web Service) has restrictions on the number of results returned.
The results parameter (the number of results "per page") has a maximum value of 20.
The start parameter (the offset at which to start) has a maximum value of 250.
Since you ask for the first 500 results, YQL makes multiple queries against the Local Search API returning 20 results at a time. Therefore the start values are 1, 21, 41, ... 241. This brings back 260 results, as you have seen.
Since the YQL query asks for more results, the next start value is tried (261) which is beyond the allowed range so the underlying service returns an error (with the message "invalid value: start (261) must be between 1 and 250"). If you turn on "diagnostics" in the YQL console, you will see the "Bad Request" being returned.
Nothing you do to the query will bring back more results than the underlying service allows.
I figured out, I was missing paging number, so 0++ will work
select * from local.search(0,500) where query="sushi" and location="san francisco, ca"

Resources