I am having trouble access tweets via twitters json search
https://search.twitter.com/search.json?callback=?&rpp=5&q=from:secretdreameruk
The strange this was it was working a few weeks ago, but all of a sudden stopped and is producing no errors.
Viewing the above link in a browser displays the json return, but the results section is empty ("results":[]), even though I have tweeted recently.
At first I thought the usage would be limited per day, but I have had this problem for about a week.
Does anyone know why this has happened?
Thank you.
Mike
I'm not sure why that seems to be happening though by twitter's own admission:
Search is focused in relevance and not completeness. This means that
some Tweets and users may be missing from search results. If you want
to match for completeness you should consider using the Streaming API
instead.
I would use the following api format instead, it's much more customisable.
https://api.twitter.com/1/statuses/user_timeline.json?screen_name=secretdreameruk&count=5&callback=?
Related
I'm building a flight search chat bot using, chatfuel, flowxo and google sheets.
when I ran the chat for the first time, it worked perfectly but when i ran it again it only displayed the search results containing the input from the first time I ran and not from the second/third/forth time. however, if I wait for some time, 15-20 minutes, the bot works as it should again. I think that maybe the problem is that the chatfuel not cleaning cache or not processing Json answers fast enough.
Has anybody encountered this issue and/or know how to solve it?
Dan.
I solved the issue. instead of displaying the Json results in the block, I add another step and now the json result are defined as user attributes and the attribute is displayed in the block
I'm trying to search WikiNews, both for specific news stories and for the latest headlines. I've been reading about the MediaWiki API (https://www.mediawiki.org/wiki/API:Main_page), but it doesn't seem to map to what I'm trying to do.
Taking two examples, I need to be able to get the latest headlines (ideally for a specific region (United States, France, Great Britain etc) and for a specific topic (Finance, Sport, Media etc), but right now I'd settle for just getting the latest stories regardless. I've tried a couple of things:
https://en.wikinews.org/w/api.php?action=query&prop=categories&clprop=timestamp&format=json
just returns batchcomplete
http://en.wikinews.org/w/api.php?action=query&list=recentchanges&rnnamespace=0 looks like it might be more promising, but only if I could filter only to show news stories - and show a good deal more than it currently does. Clearly it would also be desirable to add parameters for location / story type in the query rather than filtering them after the list is received.
With regard to searching, I've had even less luck. I've tried searching on a topic that I know is ~~causing trouble~~ making the news:
https://en.wikinews.org/w/api.php?action=query&titles=Donald_Trump&prop=revisions&rvprop=content&format=json&redirects&continue the return is not a list of stories!
Has anyone searched WikiNews? Does anyone have any suggestions to achieve what I need to do?
action=query&format=json&list=search&redirects=1&srsearch="Donald Trump" -incategory:disputed incategory:"August_25, _2016|August_24,_2016|August_23,_2016|August_22,_2016|August_21,_2016|August_20,_2016|August_19,_2016|August_18,_2016"&srnamespace=0&srenablerewrites=1 will search for articles from the last few days mentioning Trump. (See full docs on what keywords can be used in a search query.)
Most of your examples do not actually generate a list (you can see from the lack of a list parameter); they expect one or more article name via the titles parameter and return information about those. Your second example is valid (except the correct parameter name is rcnamespace) but that returns recently edited articles, which is a very random way of trying to find news on a topic.
In general it seems like you are trying to randomly guess what the API modules do. Did you miss the docs and sandbox?
Relative newbie here :)
Since twitter just recently disabled their endpoint count (http://urls.api.twitter.com/1/urls/count.json?url=), which they announced here, what would be a good alternative to get the current number of tweets per URL, with "good" being a JSON and hundreds of requests per day?
Only thing I found that might be good is Topsy's search by link.
I have the same problem, you can try
http://opensharecount.com/
or look at this post. The first method works
How do I Fetch Twitter Share Count via PHP after the upcoming update?
Yeah, http://opensharecount.com uses Twitter's REST API on your behalf so you don't have to do the counting and storing of previous result counts (the search API only returns data that is up to a week old or so, so you have to keep track of what the most recent search result was the previous time you counted or the count will go off).
OpenShareCount returns JSON in exactly the same way the old Twitter API did, all you need to do is replace the broken URL with the new one. You do need to sign up though, because it needs to do searches on your behalf.
You must be using a different Twitter API, we are effectively counting thousands of tweets. And yes, the service is limited to the domain you sign up with but nothing stops you from signing up with multiple twitter accounts, one per domain you need info for.
When I use the search functionality on the scribd docs API to search for a function, like
http://api.scribd.com/api?method=docs.search&api_key=API_KEY&query=hello+world
It returns irrelevant results, and ones different to the search functionality of the site. This request, for example, returns results about Guitar Hero, World of Warcraft and Virtual Worlds etc. Whereas the site search on https://www.scribd.com/search-documents?query=hello+world gives documents titled "Hello World" as you would expect. Is there a parameter that I can add to the api call that will make it return relevant results?
You may try playing with the simple parameter to see if it makes any difference to your queries. According to the API reference (half of it is inaccessible at the moment) it makes the results the same as for the website:
(optional)This option specifies whether or not to allow advanced search queries (more information). When set to false, the API search behaves the same as the search on Scribd.com. When set to true, the API search allows advanced queries that contain filters such as title:"A Tale of Two Cities". Set to "true" by default.
I tried your query myself, but it still doesn't give adequate results, even though it changes things a bit. But it is still not good enough regardless of the simple option being set to false. Even if you try to run their sample queries 1:1 they are still giving 90% irrelevant results.
Then I found a similar issue being discussed in the following google group thread back in 2011. At the end Jared Friedman (the CTO of Scribd) himself admits that API search and website Search work differently and it is not in their priorities to fix this. In 2014 another developer complained. Seems to me that four years later this is still the case.
I'd suggest contacting Scribd support directly and asking them what is the current status of the docs.search API and if there is some preliminary approval process in place (for example, they may do a background check on accounts and only then provide relevant results, otherwise they return just test results for any query) although I doubt it.
I'm a bit stuck with one thing. Just can't make up my mind on whether to use POST or GET method at my search form.
Normally I would use GET method for such a form, so users could bookmark their results they got. But this time, the search form is present in administration area, so results are relevant shortly and there is no need to bookmark results and of course, they aren't public for everyone.
To be more specific, the search feature is meant to be used along with a list of users, so there could be some specific user to be searched. My idea was to use POST method, where the form would be redirected to the same page so I would get a list of users filtered by search string. There was also pagination, so I would add the search string at the and of each pagination link (next page, previous page, first page and last page link) so the search string wouldn't be lost later on (within any session coming after the search like paginating of searched results etc.).
There is no obvious reason to prefer one before another, both can be used. The POST method would be a little bit more hassle, but on the other hand, there are advanced options within the search form (about 5 checkboxes) and I don't like the idea of having meesed up URL bar with way too many values (and I expect users not to use pagination after search session so often, so the values wouldn't get to the address bar so often) if POST method used.
Which one would you prefer for searching in CMS and alike systems?
Thanks everyone!
You are getting data, so use GET. POST will create issues with refreshing and going back.
Don't obsess over the beauty of your URIs, they are a tool not a piece of art.
Maybe, I would (mostly) always choose post over get, it's more tidy and refreshing and going back issues with post method are a thing from the past in any major browser, they just ask you if you want to resend the data, don't they?
The MAJOR exception would be bookmark of a dynamic webpage (like movieweb.com/movies.php?movie=the_three_mosqueteers, for example), but still, if that's not the case I think it's better to use POST.