Could anyone please summarize the differences between Twitter's REST API and its Streaming API?
And does either of them uses Push technology?
The REST API lets you query or modify a user's account. You don't need their permission to query their account, you do need it to modify their account. They provide permission through OAuth authentication.
The streaming API delivers tweets based on search terms or for specific users you request, along with info about the author, in real-time. You do not need the tweet author's permission. You must log into some Twitter account to use streaming, using either basic or OAuth authentication.
Neither uses push, but streaming is a continuous net connection, so it is real-time delivery, making it functionally similar to push.
For anybody coming to this more recently, The REST API (v1.0) has now been retired with v1.1 being the only version. This Does now require authentication for everything, including reads.
Authentication required on all endpoints
In version 1.1, we're requiring applications to authenticate all of
their requests with OAuth 1.0a or Application-only authentication. Not
only will this visibility allow us to prevent abusive behavior, but it
will also help us to further understand how categories of applications
are using the API. We'll apply that understanding to better meet the
needs of developers as we continue to evolve the platform. At this
time, all authentication requires user context, but in the coming
weeks we'll be pushing out support for a form of authentication not
requiring a user context.
Actually you can use search through the REST API as well. For example it's the only way to combine geo AND query keyword, while the Stream API can only use OR logic.
I think it's about defacto push streaming as Adam Green has said.
Related
The JavaScript chat client SDK is missing some functionality that the REST API has, like list users. Should the 1st person chat client be using the REST API as well to supplement gaps in the client SDK or just in general? Or is it strictly for backend management?
Twilio developer evangelist here
The Chat SDK itself doesn't give all of the same access as the REST API because that would put that access directly in the hands of all users of the Chat SDK. Restricting things like listing users of the app to the REST API means that your application has greater control over those functions and can restrict access or use it only in specific circumstances.
As we've discussed in your other question, how you actually manage things in your application, whether it is by calling to the REST API or storing data in your own user database, is up to you and depends on what will work best for your application.
I'm trying to work out the best architecture for a couple of apps I'm developing.
In both apps I want to utilise google/twitter/LinkedIn/etc to provide authentication of a users identity. The app is composed of an iOS app which has an option to send data to a server which I'm writing in node.js.
I want to utilise either OAuth or OpenId to handle identifying a user against the above servers so that I don't have to put in an authentication system of my own. In other words, allowing users to re-use their ids when choosing to upload data.
I should also note that apart from identifying a user, obtaining a name and email address, I have not intention of using any of their APIs at this time.
I think I have two options:
Place the Authorisation code in the iOS client and transmit some sort of key to the server with the data which it can then verify.
Keep the iOS client fairly dumb, and handle authorisation from the node server.
I'd probably prefer the second option because it means I could centralise authentication and be able to support a web site as well. That's my current theory.
Can anyone who has done something like this give me some pointers as to the pros and cons, OAuth or OpenId, or links to some examples?
In our previous app we opted for a combination of the two approaches. We wanted to centralize our user data on our server in the event we needed to make future API calls on those services. We also wanted the native oAuth experience for the user on the client. Ie: on Android and iOS, the developer can have single sign-on / authorization run through the native Facebook app (if available), vs. popping-up a webview that serves the 'Approve' dialog. It's a better user experience in my opinion. Also for Twitter, the oAuth process may require a PIN code to be entered in the callback which should probably be handled on the client side.
You can pass the access token retrieved by the client to the server for storage and later use if you intend on making additional API calls on these services, provided you expect the token to be long-lived (ie: offline-access permission on FB).
In any case this is mostly a user experience decision.
I have a little app that mines data on social networks and returns interesting results (e.g. the latest conversations around a certain topic). However, the front end requires that the users connects with the various services first via oauth, before these services' APIs can be scanned.
I would like this process to be automated on the server, so that a person using the app does not need to auth with Twitter, Fb, Linkedin in etc just to get results from those services. Is this possible?
No. This is not possible. The OAuth specification requires a user to first authenticate with the service and then authorize your application to request data on the user's behalf.
For twitter there is a hack: search, search, search! and 'connect' the tweets yourself :-)
This hack works for apps like http://jetwick.com
I have some PHP creating automatic Twitter updates, which in the small print at the bottom reads "[date/n minutes ago] via API".
Is it possible to somehow change the "via API" part to something more useful and descriptive?
It looks like you have to utilize OAuth authentication. As per the Twitter API Wiki:
How do I get “from [MyApp]” appended to updates sent from my API application?
We now recommend developers use OAuth to perform authentication with the API. When applications use OAuth, Twitter automatically knows the source of status updates. We are therefore able to append source attribution (from "[MyApp]") to tweets. If you would like tweets from your application to recieve a source parameter, please register an application and implement OAuth authentication. We will automatically include your application as the source for any tweets sent from your application.
We originally allowed applications to create a source paramter for non-OAuth use but that has been discontinued. Applications pre-OAuth source parameters will remain active, but new registrations are no longer accepted.
I am building a twitter application that is currently using the classic login instead of OAuth. Does Twitter have any plans of deprecating this? I chose not to do OAuth because it is still being piloted as a beta.
I doubt there are any plans to deprecate the old API, because there are hundreds of applications which are designed to use it. Even though it's safe to use the old API, if I were you, I'd transition to OAuth due to user security concerns. OAuth is more secure than the plain API, and provides fewer ways for an attacker to obtain the user's password.
From the Twitter API documentation:
OAuth is the Twitter preferred method
of authentication moving forward.
While we have no plans in the near
term to require OAuth, new
applications should consider it best
practice to develop for OAuth. We
eventually would like to suspend Basic
Auth support. However we realize that
Basic Auth has been a large part of
the API's success, and that the
barrier to entry if OAuth is the only
solution is substantially higher. Many
applications rely on Twitter accounts
as their means of account management.
Additionally, Basic Auth allows a
developer with a command line, cURL,
and his account credentials to start
poking at Twitter data. There are
still a number of archetectural use
cases to work through before we
consider the deprication of Basic
Auth. Before any changes begin to
happen, we will discuss them with the
community through the support
channels, and give at least 6 months
lead time before making any policy
changes.
"When are you going to turn off Basic Auth?
We announced in December of 2009 the deprecation of Basic Auth. Its removal date from the platform is set for June 2010. We announced towards the end of June 2010 that we have postponed this until August 16th 2010."
--from http://dev.twitter.com/pages/oauth_faq
I believe using Oauth would be the safest bet, and its more convienet in the long run. I read an article saying that twitter is making Oauth mandatory pretty soon as well so you will have to switch over eventually.
It would be best if you provide both mechanisms to your clients, by default the classic login but if user is concerned about security they can choose the OAuth mechanism.
Mind it, many users will leave your application just because it requires them to give your application their (user's) credentials.