-Stream only tracks keyword tokens. TweetHook uses the Twitter Search query syntax.
- Using the stream requires a dedicated server with a dedicated TCP connection resource to consume and parse/handle the data. TweetHook only requires that you have a web server somewhere that can handle POST data. Also TweetHook supports multiple endpoints, whereas the Stream can only terminate in one location.
- Using the stream requires the consumer to multiplex the data and determine what keyword was matched when receiving data. TweetHook provides the actual query that was matched with the POSTed data. No multiplexing required.
- The Stream requires a good bit of technical knowhow to get it running correctly. TweetHook aims to make receiving search data easy and accessible to anyone who has a website and knows some scripting. A Wordpress plugin could be developed, for example, to receive and display tweets relevant to the blog's content. Tweets could then be loaded from a local cache instead of depending on fetching data from the Twitter servers using a javascript widget (which usually delays page loads).
- Currently the Stream and the Twitter Search data have different EULAs/TOS (this could change, of course).
This question is something I have thought quite a bit about as the Streaming API was launched after development on TweetHook had started. Currently I do not point out these differences on the website since I did not want to make it look like I was downplaying the Streaming API, which in itself is actually pretty cool.
Personally, I think that webhooks are more accessible to developers, and eventually to more tech savvy users like some bloggers. That's my $0.02 at least.
