The StockTwits API documentation describes steams in a way that sounds like static search results, for example streams/symbol:
This allows an API application to search for a symbol or user. 30 Results will be a
combined list of symbols and users.
This seems similar to search/symbols:
This allows an API application to search for a symbol directly. 30 Results will return
only ticker symbols.
Other than the fact that search excludes users, I don't see the difference.
In contrast, the Twitter API provides methods to request a continuous stream of tweets, which I have gotten to provide tens of thousands of tweets in a few days.
Is it possible to have StockTwit pump tweets continuously, similar to Twitter?
If so, what is required? Since StockTwit streaming looks like searching to me, the only option I have seen is to submit repeated search requests, but that would exhaust the rate limit.
I prefer C#, but I am glad to study answers in other languages, such as PHP.
This is a static search for symbols or both symbols and users as a combined search. This isn't a streaming search endpoint for filtering content. This is strictly for use for finding a symbol or a user to go directly to the stream.
We are looking into offering streaming endpoints and search would be part of this offering.
You may be interested in using streamdata.io which allows to stream any APIs. We have already implemented a StockTwits demo, which can be found here and explanations can be found in this blog post.
I think it's quite easy to transpose what has been done with Android to the C# world. All you need is an EventSource library and a JSON-Patch library.
Related
I am trying to obtain the total result count from manual Google web search via the CustomSearch API. I am searching the entire web based on a keyword and an associated site, so the search query is " site:". Judging by my research, it is a known issue that manual Google search results tend to differ from CustomSearch API results obtained from searching the entire web, as cited here and elsewhere.
Is there really no way to exactly reproduce manual search results with the API? If that is the case, then the API is rather limited and should be explained up-front to developers in the documentation or fixed.
My custom search engine is already set up to search the whole web I believe.
It looks like maybe PDF files returned in a web search are not returned by the API. I have already tried specifying fileType parameter to include PDFs to no avail.
3 Results returned via manual web search.
0 results returned by API.
If anyone has lessons to share I will be thankful!
I am very confused about the correct or recommended mechanism to use for accessing google fusion tables APIs in app scripts. There seem to be two methods with examples but no discussion about which is preferred or why. Is one of these interfaces newer and preferred while the other is dying? Is one obsolete or more restricted in what it can do?
Method 1 is the REST API described here
https://developers.google.com/fusiontables/docs/v2/sql-reference#Select
Method 2 is a set of library functions sort of described here under the Apps Script/Google Advanced Services:
https://developers.google.com/apps-script/advanced/fusion-tables
For example, using the REST api to do a dql query, we end up with something like this:
function runSQL(sql){
var getDataURL = 'https://www.googleapis.com/fusiontables/v1/query?sql='+sql;
var dataResponse = UrlFetchApp.fetch(getDataURL,getUrlFetchOptions()).getContentText();
return dataResponse;
}
And using the advanced API we use something like this:
result = FusionTables.Query.sql(sql, { hdrs: false });
The REST API seems much harder to use, requireing complex oAuth and developer keys to be configured in advance and coded into the application while the Advanced Services API harvests all this behind the scenes and makes for simple API calls like I show here.
I have seen numerous examples using each of the above with no hint as to why one author chose her mechanism instead of the other.
Your help is greatly appreciated.
The service within app-script is a work in progress, so the full functionality of the API might not be fully supported at the moment. As you mentioned though, the big advantage of the service over the REST API is that you do not have to handle the OAuth flow, as you only need to enable it on your script (as stated here).
The Apps Script "advanced service" implementation still lacks some advanced functionality (like alt=media format queries or multipart / resumable uploads) -- if it actually has those features, it lacks extremely basic documentation of them, to the point that the Apps Script editor autocomplete is unaware of them. The tradeoff of these functionality gaps is that you don't need to handle keys, request building, etc.
So, if you're doing simple sql select / importRows work, the Advanced Service should be able to cover almost all your needs. If you need to delete from your FusionTables, you might want to consider setting up the REST API - because deleting is 1 record per query, the better way to delete is to instead "download what you want to keep, then re-upload it back via replaceRows."
(This worked for me for a while, but eventually what I was keeping outgrew the Apps Script service's limitations and I began receiving Empty Response errors from the call to replaceRows. My remedy was to perform my record maintenance tasks via the REST API, where I can specify resumable uploads, timeouts, etc., while more "normal" interactions are done through the Advanced Service.)
I've been looking around the internet for information on Koha ILS restful api but I haven't found anything concrete. There is this link which talks about its HTTP API: http://wiki.koha-community.org/wiki/Koha_/svc/_HTTP_API but there are no examples and I'm quite confused with the MARCXML format required.
What I want to do is use this API to create biblio records into a remote Koha ILS system. If I understand correctly, using these services I can create records (probably using a JSON-to-MARC convert tool) but will I be able to also upload pdf files of each record in BASE64 format? It doesn't look like this is possible using this API although I'm not really sure.
The HTTP API available in Koha is a well-established protocol, called SRU, for searching library catalogs. This is protocol is meant only for searching, not for updating records.
Secondly, even though SRU 2.0 provides option for transmission of records in JSON format, most implementations do not support it yet.
Coming back to your use case, Koha cannot store PDF documents. It is a process automation tool in a library for physical collections, which deals only with metadata records. For storing digital documents you should look for document management solutions, such as DSpace, or smaller and easier Omeka. DSpace provides its own REST API for searching as well as supports SWORD protocol for uploading documents.
Call me crazy, but I'm looking for a service that will deliver autocomplete functionality similar to Google, Twitter, etc. After searching around for 20 min I thought to ask the geniuses here. Ideas?
I don't mind paying, but it would great if free.. Also is there a top notch NLP service that I can submit strings to and get back states, cities, currencies, company names, establishments, etc. Basically I need to take unstructured data (generic search string) and pull out key information with relevant meta-data.
Big challenge, I know.
Sharing solutions I found after further research.
https://github.com/haochi/jquery.googleSuggest
http://shreyaschand.com/blog/2013/01/03/google-autocomplete-api/
If you dont want to implement it yourself, you can use this service called 'Autocomplete as a Service' which is specifically written for these purposes. You can access it here - www.aaas.io.
you can add metadata with each record and it returns metadata along with the matching results. Do check out demo put up on the home page. It has got a very simple API specifically written for autocomplete search
It does support large datasets and you can apply filters as well while searching.
Its usage is simple - Add your data and use the API URL as autocomplete data source.
Disclaimer: I am founder of it. I will be happy to provide this service to you.
In my iPhone app I am trying to gather feedback on my game via an optional survey. I would like to send this data to a central server, where I could gather all the statistics and process them to have a bar chart or other convenient presentation.
The data being sent an integer representing the user's preference. ie) Given "How did you like our game?", the user could select from a button from :) :\ :( . Eventually I would also like to have audio feedback where the user could record their voice. The variable length sound clip would be sent and stored from an iPhone to some server, for playback later.
Has anybody done something similar? Google Spreadsheets offers an API which I can't make heads nor tails of but I think it will support a tally of responses. ie) I received 10 goods, 4 neutral, and 7 poor ratings. As far as I can tell I wouldn't be able to store a sound clip in a spreadsheet.
I also looked into Google App engine but if possible I'd like to avoid the networking code to transmit the survey data and the server side scripts to interpret the data. Can somebody recommend a simple API that I could use to store integers for viewing? Ideally I'd like to say something simple like
if (response == "Good") MyGoogleSpreadsheet.MyAppStats.Increment(positiveResponseTallyCell);
Later on I'd just log into Googlespreadsheets and the results would be there for me to read. By the way I don't have to necessarily use a spreadsheet. I just want this to be easy. Bonus points if the API supports the storage and playback of sound but integers will suffice for now.
You can do this with the Flurry API (flurry.com) which lets you specify which custom events to log, and gives you charts and downloadable CSV. Very easy to use:
[FlurryAPI startSession: flurryID];
[FlurryAPI logEvent:#"QUESTION1" withParameters:#"Good"];
Although Flurry is made for general usage statistics gathering, I think it would be a quick and easy way to accomplish what you want.
I know you said you've already taken a look at the Google Spreadsheets API, but you may not have seen the GData Objective-C framework which includes support for reading/writing to and from Google Docs spreadsheets (via the GDataServiceGoogleSpreadsheet class).