Now, why would I want to do this? I’m not 100%, which is why I’m writing this story.
I just need to adjust the polling frequency in my Streamdata.io settings to make sure I am not going to go over my Twitter rate limits, then I have myself a pretty robust streaming and cached source of my Twitter List. Providing a pretty simple stream of Tweets without the overhead of using the Twitter Streaming API.
#TWEETDECK LOGIN TWITTER BYPASS CODE UPDATE#
At first I get the entire response from the API, but then I just get an incremental JSON Patch update with any additional Tweets. The result is a pretty efficient stream of Tweets from any accounts on the Twitter list I maintain for the API industry. However, once I saw that it worked, I added the authorization header to my Streamdata.io settings so I can keep it out of the code, simplifying each request I am making to Streamdata.io. At first I passed the header in with call I made to Streamdata.io. Then you just make sure and include in a Authorization: Bearer with each request. To stream a Twitter list using Streamdata.io all I did was use the URL for the Twitter lists statuses API, with two query parameters. I’ve integrated with the Twitter Streaming API before, but I wanted to understand the technical details of how its different than using Streamdata.io, and HTTP Server-Sent Events (SSE) and JSON Patch. Technically Twitter is just using a long-lived HTTP request, establishing a persistent HTTP request, and making data available in a regular stream of HTTP responses.
Which is kind of senseless as Twitter has their own streaming API, but it can be a little more investment to get up and running with both technically, and in a businesses sense if you are needing higher volumes, than Streamdata.io. I was playing with streaming different APIs, and I found myself playing with the Twitter API.
0 kommentar(er)
