[twitter-dev] Formats for specifying annotations
Hey folks. I'd like to get your advice on the Annotations feature. Specifically on how you should specify your annotations when creating an annotated tweet. Our first gut impression was that we should let people specify annotations in JSON or as form encoded parameters with the request. This would serve various use cases. The JSON option would be well suited to libraries that programmatically build up a request. The form-encoded parameters case would be well suited for situations where a form programmatically builds up a set of annotations. In the course of developing the feature though, when we went to create some test annotated tweets via twurl we realized just how tedious and unreasonable it would be to specify annotations in JSON or even form-encoded parameters in that case. There is a place for specifying your annotations with JSON, but we think there also needs to be an easier way too. If only so that debugging and testing can be done more expediently. So we built a simple format, similar to the notation Flickr exposes for searching images with a given machine tag. Here are some examples. A single annotation with one attribute: book:title=Catcher in the Rye This maps to: Annotation type: book attributes: title - Catcher in the Rye A single annotation with two attributes movie:title=Terminator 2url=http://www.imdb.com/title/tt0103064/ This maps to: Annotation type: movie attributes: title - Terminator 2 url - http://www.imdb.com/title/tt0103064/ Two annotations, each with one attribute: movie:title=Terminator 2,actor:name=Arnold Schwarzenegger This maps to: Annotation type: movie attributes: title - Terminator 2 Annotation type: actor attributes: name - Arnold Schwarzenegger I find this simple format both simple to write and natural to read. But unfortunately it's flawed in about a dozen ways. For one, it uses several characters that are already used in query strings to specify parameters. Specifically '' to separate multiple parameters and '=' to indicate the value of a given parameter. So if you're using twurl, it's very easy for you to confuse the hell out of it :-) For example: twurl /1/statuses/update.xml \ -d status=Tweet with annotations!annotations=movie:title=Terminator 2url=http://www.imdb.com/title/tt0103064/; Sure you could URL encode the annotations parameter but there goes the convenience of the simple format. Second problem: We want to allow you to use any arbitrary set of bytes for the type, attribute names and attribute values of an annotation. With this simple format though, if any of your values contain one of the characters used to specify the simple formatted annotation, e.g. colon ':', comma ',', ampersand '' or equals '=', then you'd have to also escape those. Edge cases and dragons around every corner. (Additionally we'd have to build a more sophisticated parser to honor your escaped characters.) The simple format's limitations could be justified by reminding ourselves that it's mostly intended for debugging and testing and so doesn't need to robustly handle every contingency. And yet the idea of putting something out there that could and will fail in mysterious ways sometimes isn't very appealing. I'd like to strike a balance between simplicity and versatility. We want a simple and natural way for people to specify their annotations (i.e. minimal use of ornate or obscure punctuation with cryptic semantics). So here's my question: How would you design it? -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Announcing Twurl: OAuth-enabled curl for the Twitter API
There is a fix for this. In the meantime you can pass in the -u and -p (username password) command line options and it will force the PIN work flow and you'll be able to authorize. On Wed, Apr 21, 2010 at 1:14 PM, Jaanus jaa...@gmail.com wrote: I can't get it to authorize. my-mac:~ jaanus$ twurl authorize --consumer-key blabla --consumer- secret blabla You must authorize first huh? On Apr 20, 3:13 pm, Marcel Molina mar...@twitter.com wrote: We've announced that come June 2010, Basic Auth will no longer be supported via the Twitter API. All authenticated requests will be moving to OAuth (either version 1.0a or the emerging 2.0 spec). There are many benefits from this change. Aside from the obvious security improvements, having all requests be signed with OAuth gives us far better visibility into our traffic and allows us many more tools for controlling and limiting abuse. When we know and trust the origin of our traffic we can loosen the reigns a lot and trust by default. We've already made a move in this direction by automatically increasing rate limits for requests signed with OAuth made to the new versioned api.twitter.com host. One of the often cited virtues of the Twitter API is its simplicity. All you have to do to poke around at the API is curl, for example, http://api.twitter.com/1/users/noradio.xmland you're off and running. When you require that OAuth be added to the mix, you risk losing the simplicity and low barrier to entry that curl affords you. We want to preserve this simplicity. So we've provided two tools to let you poke around at the API without having to fuss with all the extraneous details of OAuth. For those who want the ease of the web, we've already included an API console in our new developer portal athttp://dev.twitter.com/console. And now today we're glad to make available the Twurl command line utility as open source software: http://github.com/marcel/twurl If you already have RubyGems (http://rubygems.org/), you can install it with the gem command: sudo gem i twurl --sourcehttp://rubygems.org If you don't have RubyGems but you have Rake (http://rake.rubyforge.org/ ), you can install it from source. Check out the INSTALL file ( http://github.com/marcel/twurl/blob/master/INSTALL). Once you've got it installed, start off by checking out the README ( http://github.com/marcel/twurl/blob/master/README) (you can always get the README by running 'twurl -T'): +---+ | Twurl | +---+ Twurl is like curl, but tailored specifically for the Twitter API. It knows how to grant an access token to a client application for a specified user and then sign all requests with that access token. It also provides other development and debugging conveniences such as defining aliases for common requests, as well as support for multiple access tokens to easily switch between different client applications and Twitter accounts. +-+ | Getting Started | +-+ The first thing you have to do is register an OAuth application to get a consumer key and secret. http://dev.twitter.com/apps/new When you have your consumer key and its secret you authorize your Twitter account to make API requests with your consumer key and secret. % twurl authorize --consumer-key the_key \ --consumer-secret the_secret This will return an URL that you should open up in your browser. Authenticate to Twitter, and then enter the returned PIN back into the terminal. Assuming all that works well, you will beauthorized to make requests with the API. Twurl will tell you as much. If your consumer application has xAuth enabled, then you can use a variant of the above % twurl authorize -u username -p password \ --consumer-key the_key \ --consumer-secret the_secret And, again assuming your username, password, key and secret is correct, will authorize you in one step. +-+ | Making Requests | +-+ The simplest request just requires that you specify the path you want to request. % twurl /1/statuses/home_timeline.xml Similar to curl, a GET request is performed by default. You can implicitly perform a POST request by passing the -d option, which specifies POST parameters. % twurl -d 'status=Testing twurl' /1/statuses/update.xml You can explicitly specify what request method to perform with the -X (or --request-method) option. % twurl -X DELETE /1/statuses/destroy/123456.xml +--+ | Creating aliases | +--+ % twurl alias h /1/statuses/home_timeline.xml You can then use h in place of the full path. % twurl h Paths that require additional options such as request parameters for example can be used with aliases
[twitter-dev] Announcing Twurl: OAuth-enabled curl for the Twitter API
hhC7Koy2zRsTZvQh1hVlSA (default) testiverse guT9RsJbNQgVe6AwoY9BA Notice that one of those consumer keys is marked as the default. To change the default use the 'set' subcommand, passing then either just the username, if it's unambiguous, or the username and consumer key pair if it isn't unambiguous: % twurl set default testiverse % twurl accounts noradio HQsAGcBm5MQT4n6j7qVJw hhC7Koy2zRsTZvQh1hVlSA testiverse guT9RsJbNQgVe6AwoY9BA (default) % twurl set default noradio HQsAGcBm5MQT4n6j7qVJw % twurl accounts noradio HQsAGcBm5MQT4n6j7qVJw (default) hhC7Koy2zRsTZvQh1hVlSA testiverse guT9RsJbNQgVe6AwoY9BA +--+ | Contributors | +--+ Marcel Molina mar...@twitter.com / @noradio Raffi Krikorian ra...@twitter.com / @raffi -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Early look at Annotations
features we're hoping to get to after Annotations. Think big. Blow our minds. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Re: [twitter-api-announce] Early look at Annotations
More namespace nesting would of course increase people's ability to taxonomize. It's a splippery slope though and we are trying to balance expressiveness with simplicity. Providing for arbitrarily nested namespaces increases complexity considerably both from an implementation perspective and a comprehension perspective. On Fri, Apr 16, 2010 at 11:45 AM, gabriele renzi rff@gmail.com wrote: * What is an annotation more exactly exactly? First off let's be clearer about what an annotation is. An annotation is a namespace, key, value triple. A tweet can have one or more annotations. Namespaces can have one or more key/value pairs. first, annotations are cool, thanks. But why triples instead of quads? Say, we'd like to store three groups of movie data . If I do movie: rating: 5 then we risk conflict with someone else using the same namespace in a different way, e.g. movie: rating: * . At the same time, if I use the namespace for my application to avoid conflicts, I have to encode two of the fields in one cascaad: movie_rating : or cascaad_movie : rating: Did you consider this and decided it's not worth making the effort for a fourth field, or just ignored the issue, or simply didn't think of it? If triples are staying, can we establish a _convention_ early on on how to best handle this? -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: [twitter-api-announce] Early look at Annotations
We definitely want to have documents on dev.twitter.com with best practices and guildelines. That will be key. We're looking for everyone to help devise the rules of the road. On Fri, Apr 16, 2010 at 11:59 AM, gabriele renzi rff@gmail.com wrote: On Fri, Apr 16, 2010 at 8:51 PM, Marcel Molina mar...@twitter.com wrote: More namespace nesting would of course increase people's ability to taxonomize. It's a splippery slope though and we are trying to balance expressiveness with simplicity. Providing for arbitrarily nested namespaces increases complexity considerably both from an implementation perspective and a comprehension perspective. I am not in favour of arbitrarrily nested, quads are ok to express almost anything useful apart from temporal logic :) (consider a namespace app: subject-verb-object). But I'm ok with you choice, just, as i said, can we at least put some guidelines so we can avoid unintentional conflicts among implementors? E.g. if you want to store triples and avoid conflicts with other applications use a namespace such as yourapp:subnamespace - key - value -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Early look at Annotations
This is a great idea for how to bootstrap and fuel the adoption and consensus on namespaces and key names. I'm going to talk to our analytics team and see if we can surface analytics on the most used namespaces and those namespace's most used keys. On Fri, Apr 16, 2010 at 1:05 PM, Jaanus jaa...@gmail.com wrote: Another 2c: you should think about publishing numbers/stats for annotations. Easiest to start on the level of namespaces. Publish stats about popularity of namespaces: how many tweets and how many users use which namespaces. And don't do that's a good idea and there are still many moving parts and we are thinking of it for the future, do this is absolutely vital for the community from day 1 :) This would be a good measure for community to inform what namespaces to support, what works and what doesn't, etc. J -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Early look at Annotations
I've talked to the analytics team. Three main metrics we're going to work to surface on something like dev.twitter.com initially (and maybe even an API so you all can build experiences/explorers around annotations): 1) All time most used namespaces/keys. 2) Trending namespace/keys. 3) Most widely adopted namespace/keys (i.e. not necessarily the most used but the ones used by the highest number of different client applications) On Fri, Apr 16, 2010 at 1:43 PM, Marcel Molina mar...@twitter.com wrote: This is a great idea for how to bootstrap and fuel the adoption and consensus on namespaces and key names. I'm going to talk to our analytics team and see if we can surface analytics on the most used namespaces and those namespace's most used keys. On Fri, Apr 16, 2010 at 1:05 PM, Jaanus jaa...@gmail.com wrote: Another 2c: you should think about publishing numbers/stats for annotations. Easiest to start on the level of namespaces. Publish stats about popularity of namespaces: how many tweets and how many users use which namespaces. And don't do that's a good idea and there are still many moving parts and we are thinking of it for the future, do this is absolutely vital for the community from day 1 :) This would be a good measure for community to inform what namespaces to support, what works and what doesn't, etc. J -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: What Exactly is a Developer Advocate? (was Re: Opt-in beta of Popular Tweets for the Search API now available)
is a bummer for me. -- Ed Finklerhttp://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.comxmpp%3afunkat...@gmail.com XMPP %3afunkat...@gmail.com xmpp%3afunkat...@gmail.com xmpp%253afunkat...@gmail.com xmpp%253afunkat...@gmail.com xmpp%25253afunkat...@gmail.com On Apr 1, 8:53 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Folks, As indicated a few weeks ago, we're launching our new *beta* enhancements to search.twitter.com and the Search API today -- it's currently rolling out to our servers. Thank you all for your feedback. *Key API Takeaways*: - During the current phase, receiving popular tweets in your API search results is *OPT-IN*. You will not see the new top results in search unless you specify the *result_typ**e* parameter on your search query string. - The result_type parameter takes one of ... read more »- Hide quoted text - - Show quoted text - -- To unsubscribe, reply using remove me as the subject. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] New Resources: Who has a tweet been retweeted by?
We've just deployed two new resources for the retweet API: * /statuses/:status_id/retweeted_by * /statuses/:status_id/retweeted_by/ids The first will return up to the first 100 user representations of those who have retweeted the tweet specified in the url by :status_id. The second will return just the ids of those retweeters for the cases where that's all you care about. Though up to the first 100 users will be returned by default, these resources both support the :count and :page parameters if you'd like to pull down fewer users. It should be noted though that for operational efficiency you can't use the :count and :page parameters to go *beyond* the first 100 retweeters. Full docs here: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-statuses-id-retweeted_by http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-statuses-id-retweeted_by-ids In conjunction with these additions we also want to provide a retweet_count parameter in the status payload for convenience. The code for this is mostly done but there are some details around cache invalidation that will likely push out the availability of the retweet_count parameter for a few weeks while we work on an infrastructure change to obviate these cache invalidation issues. But we just wanted to give you a heads up about that too! P.S. Thanks to everyone for weighing in on the naming of these resources ( http://twitter.com/twitterapi/status/10538921196) -- Marcel Molina Twitter Platform Team http://twitter.com/noradio To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [twitter-dev] Changing the Content-Type header for OAuth token exchanges
This change has been deployed. Let us know if things get wonky. On Mon, Mar 8, 2010 at 3:39 PM, Mark McBride mmcbr...@twitter.com wrote: All - Per issue 1263 (http://code.google.com/p/twitter-api/issues/detail?id=1263) (and the OAuth spec), we're looking to change the Content-Type header for OAuth token exchanges to 'application/x-www-form-urlencoded'. To date it has been 'text/html'. We want to ensure that this will not break existing applications, so if you have any qualms please voice them here. ---Mark http://twitter.com/mccv -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Rate limit bumped to 350 for OAuth REST?
If you are using the api.twitter.com endpoint and signing your request with OAuth, you automatically get this higher rate limit. It's currently at 350 but we are planning on gradually ramping it up to a higher level. This was announced on this mailing list around the original announcement happened at the Le Web conference in early December. On Mon, Jan 25, 2010 at 9:25 AM, Jaanus jaa...@gmail.com wrote: I am experimenting with some clients. In the last few days, I'm seeing: X-Ratelimit-Limit: 350 AFAIK this hasn't been announced/acknowledged anywhere, so not sure exactly what's going on, just wanted to shout out here. I am only using OAuth and normal REST. I don't know if/how this affects Basic Auth and search API-s. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010
That post is a follow up to his argument for why the SUL doesn't represent as much value as some might perceive it to. It's an argument for getting rid of the SUL as it's currently implemented. There are only 500 or so people on the SUL. Non SUL users with as many followers, though rare, likely have a far more engaged set of followers. We're actively devising various mechanisms for making it a lot easier (and faster) to consume someone's full follower list. On Wed, Jan 6, 2010 at 5:36 AM, Dewald Pretorius dpr...@gmail.com wrote: This blog post by Anil Dash makes an excellent case for why Twitter should cap the number of followers that a Twitter account can have. It will make life easier for everyone. http://bit.ly/6Al7TU -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: API Latency on January 5th
The new dev site will indeed have a status dashboard. On Tue, Jan 5, 2010 at 8:07 AM, Dewald Pretorius dpr...@gmail.com wrote: Thanks John. I hope that included in Marcel's announced improvements will be an API status area where we can see that you are aware of issues. Take a page from Facebook in that regard, with their Platform Status page. On Jan 5, 12:02 pm, John Kalucki j...@twitter.com wrote: We're very, perhaps acutely, aware. Typos by iPhone. On Jan 5, 2010, at 7:55 AM, Dewald Pretorius dpr...@gmail.com wrote: Are you Twitter folks aware that the API has been kicking up a huge dust storm of 502s on all API calls, beginning somewhere on January 4th, and still continuing at time of writing (11:00 AM EST)? -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Private list statuses are missing many tweets
Could you tell me your screen name and I'll pass your issue along to the team that maintains the list backend. On Mon, Jan 4, 2010 at 6:03 PM, Aaron Rankin aran...@gmail.com wrote: I have a private list and both on twitter.com and via GET list / statuses, many tweets are missing. I confirmed this behavior by comparing the most recent tweets of several users to their public timelines. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010
Dewald, it should be noted that, of course, not all 200 request responses are created equal and just because pulling down a response body with hundreds of thousands of ids succeeds, it doesn't mean it doesn't cause a substantial strain on our system. We want to make developing against the API as easy as is feasible but need to do so in a spirit of reasonable compromise. On Mon, Jan 4, 2010 at 5:59 PM, Dewald Pretorius dpr...@gmail.com wrote: Wilhelm, I want the API method to return the full social graph in as few API calls as possible. If your system can return up to X ids in one call without doing a 502 freak-out, then continue to do so. For social graphs with X+n ids, we can use cursors. On Jan 4, 6:07 pm, Wilhelm Bierbaum wilh...@twitter.com wrote: Can everyone contribute their use case for this API method? I'm trying to fully understand the deficiencies of the cursor approach. Please don't include that cursors are slow or that they are charged against the rate limit, as those are known issues. Thanks. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Loose ends for List and Retweet APIs
There are some loose ends that need to be tied up in both the List and Retweet APIs to round out the feature set and fix some bugs. I want to crank these all out. So here is a little list I've been building. Please add what I've left out and you think is missing. Retweet: * add retweet_count to every status representation * support paging through the resource that returns all retweets for a given tweet * don't require authentication for *most* read only resources List: * on a user representation, show list count, list memberships count and list subscriptions count * don't require authentication on read only resources * expose a list of ids for a list's members and subscribers (this change will go hand in hand with a new bulk user lookup resource where you provide a list of ids and get back a list of user representations) * count parameter for status timelines of a list appears to do nothing Many other things I'm sure... -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Getting retweets in user timelines
The backwards compatibility problem is SAX event based parsers that, without proper code in place to set the current context, will just blindly grab the screen_name and text attributes etc in potentially non-deterministic ways thus mixing up, potentially, the tweeter from the retweeter, and the tweet from the retweet. On Wed, Dec 16, 2009 at 1:36 AM, Rich rhyl...@gmail.com wrote: I don't see why we even need it to be backwards compatible as technically it already is surely? The home_timeline status's are the actual retweet, to make it new style retweet compatible you need to explicitly handle the retweeted status nodes. On Dec 15, 4:06 pm, Cameron Kaiser spec...@floodgap.com wrote: Not ideal but for any users whom you have authorized credentials for you can use: http://apiwiki.twitter.com/Twitter-REST-API-Method:-statuses-retweete. .. Definitely not ideal. +1 for There are several threads looking for a way to get built-in retweets via teh user_timeline as was available before with organic (i.e., RT ...) tweets. Has there been any decision made on what will be done here? Built-in retweets are invisible to the user_timeline which is a loss of functionality. Simply including the option of retweets=true should solve the backwards compatibility option. -- personal: http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- MOVIE IDEA: From Russia with E-mail Signature -- -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Loose ends for List and Retweet APIs
Or conceivably (though arguably janky) there could be an additional parameter you provide for the user timeline that opts you in to having retweets appear. e.g. ?include_retweets=true On Fri, Dec 18, 2009 at 3:08 PM, Cameron Kaiser spec...@floodgap.comwrote: It would be good to be able to get retweets in a user's timeline. If that is not possible for backwards compatibility reasons, is it possible to have a function such as retweets_by_user which has similar semantics to retweets_by_me, except we can specify the user whose retweets are being retrieved (requiring appropriate authentication for protected users, of course)? Or, simply a parameter to ask for them optionally? I don't mind this method, but it requires two calls to assemble a user timeline. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- The more corrupt the state, the more numerous the laws. -- Tacitus - -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] friendships/create method and 403 ambiguity
In the long term we plan to add internal error codes to every non 2** response so that the consumer can unambiguously know what error they got without munging error message strings (who's language might be changed innocently not knowing the consequences). On Mon, Dec 14, 2009 at 2:42 PM, Mark McBride mmcbr...@twitter.com wrote: The body of the response allows you to differentiate these two codes, e.g. curl -ucredentials -XPOST -d http://twitter.com/friendships/create/atebits.xml ?xml version=1.0 encoding=UTF-8? hash request/friendships/create/atebits.xml/request errorCould not follow user: atebits is already on your list./error /hash On Mon, Dec 14, 2009 at 2:38 PM, shiplu shiplu@gmail.com wrote: There are two phrases about friendships/create. 1. If you are already friends with the user an HTTP 403 will be returned. 2. This method is subject to [1]update limits. An HTTP 403 will be returned if this limit as been hit. How to differ those two status codes? [1] http://help.twitter.com/forums/10711/entries/15364 -- A K M Mokaddim My talks, http://talk.cmyweb.net Follow me, http://twitter.com/shiplu Innovation distinguishes bet ... ... (ask Steve Jobs the rest) -- ---Mark http://twitter.com/mccv -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Omissions from the Changelog
Thanks for going through the bother of compiling this Abraham. These are mostly my fault. I think years of maintaining open source projects made me burn out completely on managing CHANGELOGs ;-) On Tue, Dec 15, 2009 at 3:52 PM, Abraham Williams 4bra...@gmail.com wrote: This is a list of some mager changes to the API that never made it onto the changelog. I didn't even bother digging for small bug fixes though I'm sure there are many. Deleted status being removed from Search API: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/0dc6d313e0c59470# Retweet methods: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/d1e0129f4be0848d?hl=en# Social Graph pagination removal: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/41369cb133175d0f?hl=en# Lists: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/617bdef9f6b08372?hl=en# Lists get descriptions: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/7beb695b9ba9d7ca?hl=en# Retweets Geotagging: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/6cb142aa57e6bec9?hl=en# Versioned API path available: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/2b70bd6ea4aec175?hl=en# Spam method: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/601c408797f2763c?hl=en# Home timeline method: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/08540da9d7d64c46?hl=en# -- Abraham Williams | Awesome Lists | http://bit.ly/sprout608 Project | Intersect | http://intersect.labs.poseurtech.com Hacker | http://abrah.am | http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Madison, WI, United States -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Twitter List API not working?
We are aware of the description parameter being (unintentionally) mandatory right now. We're working on a fix. Thanks. On Tue, Nov 24, 2009 at 2:18 AM, alan_b ala...@gmail.com wrote: it is just me or everybody else as well? the List API seems down at the moment i tried to create a list using the API example: --- curl -u user:pass -d name=friends http://api.twitter.com/1/31337geek/lists.xml i've got a normal response --- ?xml version=1.0 encoding=UTF-8? list id3780302/id namefriends/name full_name@31337geek/friends/full_name slugfriends/slug description/description subscriber_count0/subscriber_count member_count0/member_count uri/31337geek/friends/uri modepublic/mode . /list and then i made a index call immediately: curl -u user:pass http://api.twitter.com/1/31337geek/lists.xml i got a empty list: - ?xml version=1.0 encoding=UTF-8? lists_list lists type=array /lists next_cursor0/next_cursor previous_cursor0/previous_cursor /lists_list did i call a wrong API? or the API is currently down? -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] List creation updated (needs description param)
The list API requiring a parameter to create/update a list has been fixed and should be deployed today or tomorrow. Thanks everyone who reported this. Sorry about that... On Wed, Nov 18, 2009 at 3:57 PM, David dch...@gmail.com wrote: I've been using the List api in my app, and just noticed that the POST method to /:user/lists.:format returned the correct response, but didn't actually create a list. I've been following this api document: http://apiwiki.twitter.com/Twitter-REST-API-Method:-POST-lists What I did notice was that the Add New List ui on Twitter.com has a description field, and so I tried the same call with an additional post param description, and it worked. The description param can be empty, but it is required to make this call work. Might be a bug? Just a heads up for anyone who might be wondering. DC -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Retweet API launched to 100% of users
Back in August we announced plans to release the Retweet feature along with an API to publish and consume retweets. Over the last few months we've been gradually opening up the feature to more users as we performance test and refine it. You can see some of the original announcement emails around retweets here: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/1e07e332ec3d449d# http://groups.google.com/group/twitter-api-announce/browse_thread/thread/08540da9d7d64c46# http://groups.google.com/group/twitter-api-announce/browse_thread/thread/3641a248d555da20# http://groups.google.com/group/twitter-api-announce/browse_thread/thread/46928276a4c78df2# Today we've launched the feature to 100% of users. You can now consume retweets via the /statuses/home_timeline resource, as well as all the specialized retweet timelines. For backwards compatibility reasons we're stripping retweets out of the friends_timeline resource as well as the user_timeline resource. If you plan on implementing support for consuming retweets from timelines, switch all instances of /statuses/friends_timeline to /statuses/home_timeline. All the relevant retweet documentation can be found here: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweet http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_timeline http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweeted_by_me http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweeted_to_me http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets_of_me http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets To those implementing this feature in your clients, I'd suggest taking some UI cues from what we've done on Twitter.com: http://s3.amazonaws.com/twitter_production/differentiating-retweets.png Notice how the retweet by @ablegrape of @wblakegray's tweet is clearly differentiated from the surrounding tweets with a distinctive retweet icon and the Retweeted by label along the bottom. This is just one way of doing it. Use whatever interface you think makes sense. What's important is communicating to your users that the tweet they are seeing was shared with them by someone they follow so they don't get confused by seeing tweets in their timeline from people they aren't following. We're just getting started with the retweet feature but we're happy with this initial v1 we pushed out. We're really looking forward to seeing how everyone works with this new API. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] French version of twitter.com launched: More translation strings now available
Twitter.com is now available in French: http://bit.ly/twitter-in-french If you're looking to add a French version of your application, we've added some of the translation strings we're using to the translations page on the developer wiki: http://apiwiki.twitter.com/Twitter-String-Translations Hope some find it useful! -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Retweets and the Public Timeline
They are intentionally removed from the user_timeline. On Wed, Nov 18, 2009 at 9:11 AM, Tyson Lowery tysonlow...@gmail.com wrote: I've noticed that with the new retweet feature, retweets no longer appear in the user_timeline API calls. Is this intentional or is this a bug? If it is a bug, any ideas on the expected fix date? I noticed a lot of complaints about this searching on twitter (like hey, retweets don't show up in my XYZ application!) If it is intentional, there is no longer a way to get public retweets using the developer API calls. Unless I am missing something? The only way I see to do this is through the retweet API calls which require an authenitcated user. Thanks for any help you can provide. I'm trying to get all the information I can before I start sinking time into writing a fix for this for my application. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Lists now have descriptions
You can now add a description to a list. The resources for creating and updating a list via the API now supports a description parameter and list payloads will include it as well. All the relevant documentation should be updated to reflect these additions: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-list-id http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-POST-lists http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-POST-lists-id http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-DELETE-list-id http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-lists Let us know if something seems amiss and we hope you enjoy! -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Retweet count in status
It's on the todo list. On Wed, Nov 18, 2009 at 4:55 PM, Remy Sharp r...@leftlogic.com wrote: I'm not sure if this has been covered already, so if it has please point me in the right direction (had a quick search too). Once piece of really valuable information on the user timeline against each status would be the retweet count. Obviously doing this ourselves via API calls could be expensive (in terms of hits we're sending), so it makes sense if it were available in the API. I can see lots of use for having just the count in there, just as we have the favorited flag. Any chance it's coming? Cheers, Remy. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] List creation updated (needs description param)
The description parameter is not required to create a list. On Wed, Nov 18, 2009 at 3:57 PM, David dch...@gmail.com wrote: I've been using the List api in my app, and just noticed that the POST method to /:user/lists.:format returned the correct response, but didn't actually create a list. I've been following this api document: http://apiwiki.twitter.com/Twitter-REST-API-Method:-POST-lists What I did notice was that the Add New List ui on Twitter.com has a description field, and so I tried the same call with an additional post param description, and it worked. The description param can be empty, but it is required to make this call work. Might be a bug? Just a heads up for anyone who might be wondering. DC -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Retweets and the Public Timeline
I don't believe so. Are you working on a javascript widget that makes authentication hard? Why do you want to access it without authenticating? On Wed, Nov 18, 2009 at 1:29 PM, Tyson Lowery tysonlow...@gmail.com wrote: Thanks for the response. Is there a way to get them without authentication? On Nov 18, 10:43 am, Marcel Molina mar...@twitter.com wrote: They are intentionally removed from the user_timeline. On Wed, Nov 18, 2009 at 9:11 AM, Tyson Lowery tysonlow...@gmail.com wrote: I've noticed that with the new retweet feature, retweets no longer appear in the user_timeline API calls. Is this intentional or is this a bug? If it is a bug, any ideas on the expected fix date? I noticed a lot of complaints about this searching on twitter (like hey, retweets don't show up in my XYZ application!) If it is intentional, there is no longer a way to get public retweets using the developer API calls. Unless I am missing something? The only way I see to do this is through the retweet API calls which require an authenitcated user. Thanks for any help you can provide. I'm trying to get all the information I can before I start sinking time into writing a fix for this for my application. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Retweets and the Public Timeline
That's a compelling point. I need to think about it. We're stripping retweets out of user_timeline because clients that don't implement retweet have the (likely) potential of creating a very confusing experience for users. Removing retweets from the user_timeline at the time seemed fine because clients could merge retweets in using the retweet timelines if they wanted to. Use cases that didn't require authentication weren't being thought about for that scenario. On Wed, Nov 18, 2009 at 5:48 PM, Jeffrey jeffreywin...@gmail.com wrote: Not having retweets in the user_timeline represents a loss of functionality. With user_timeline you can get the tweets of any user using the id parameter, but there is no way to get the tweets of another user using home_timeline without being authenticated *as that user*. So this limits the ability of applications to gather info for a user without requiring them to log in. Before the retweet funcdtionality was added, organic retweets were of course visible. The built-in retweets are not. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Bad ssl certs on some servers for api.twitter.com/1 ?
Ops has been trying to track down this problem for a while. They confirmed that all servers have the correct cert. The current hypothesis is that there are some rogue servers that are being load balanced to that we don't expect to be accepting api.twitter.com traffic that do not have the correct cert. Sorry it's not fixed yet. We hope we can figure it out soon as it's a blocker for the transition of api traffic from twitter.com to api.twitter.com. On Tue, Nov 17, 2009 at 7:41 AM, Mageuzi mage...@gmail.com wrote: I've been having this same issue when connecting to https://api.twitter.com. I would have thought that if it is a problem with my code, I would always get this error. However, it is intermittent. Most times it works, but a few times an hour I will get the error. Also, I never have this problem with https://twitter.com. On Nov 15, 6:46 pm, John Adams j...@twitter.com wrote: On Nov 15, 2009, at 1:16 PM, Tim Haines wrote: Hi there, I'm doing some dev work and I'm getting occasional ssl errors when making calls against api.twitter.com/1. The most recent was posting to favorites/create. Is it possible some of the servers have bad certificates? Or is it likely I'm doing something very wrong? All of our servers have the same certificates; We have had some people report a similar issue before and we verified all of the certificates at that time. I do know of people having validation issues when they don't have current versions of OpenSSL, a current Root CA bundle, or their code has problems processing chained SSL certificates. Which program are you using to make requests against api.twitter.com? curl? Firefox? Twitter's SSL certs are issued by RapidSSL/Equifax. Make sure you have the proper root CA certs installed. If you're using OpenSSL libraries directly, remember that OpenSSL ships without any Root CA certs installed. Curl users will have similar problems as well -- you'll want to run mk- ca-bundle to get the proper ca-bundle installed. The TTYtter developers have a script that pulls the current CA bundle from Mozilla, here: http://www.floodgap.com/software/ttytter/mk-ca-bundle.txt -john -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Retweets - where are they placed on timeline
Should appear as a new tweet with the time of the retweet, not the original tweet creation time. That assumes though that no one else has retweeted it to you yet. If someone else has then this additional retweet won't appear in your timelines except for the statuses/retweets/id resource that lists up to 100 retweets for a given tweet. Duplicates are collapsed out of the other timelines. On Tue, Nov 17, 2009 at 11:46 AM, Tim Haines tmhai...@gmail.com wrote: Hi guys, I'm wondering if anyone can clarify. The services I run often shown tweets that are several months old, and offer the RT button next to them. If someone clicks to RT the tweet, how does the tweet get presented to people that aren't following the original tweeter? Is it placed at the top of the timeline appearing as a new tweet, or is it placed at the time the original tweet was tweeted? i.e. months ago, so likely to never be seen? If it would be placed months ago, it makes RT pointless for older tweets, in which case I'll switch to 'classic mode' RT's. Tim. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: Retweets - where are they placed on timeline
The retweet feature is currently rolled out to 50% of users. We gradually ramping it up. Full availability should be soon unless issues arise as we incrementally roll it out. Thanks for your patience. It's awesome to have people ready to pull the trigger on retweet. On Tue, Nov 17, 2009 at 1:27 PM, Rich rhyl...@gmail.com wrote: Does everyone have access to the ReTweet beta now? If not when is expected deployment. I have a fully working ReTweet API implementation but I don't want to submit it to Apple until everyone has access to it. On Nov 17, 9:19 pm, Marcel Molina mar...@twitter.com wrote: As Tim mentioned, clients are empowered to uncollapse retweets if they'd like. On Tue, Nov 17, 2009 at 12:37 PM, Dewald Pretorius dpr...@gmail.com wrote: Marcel, This collapsing behavior is far from ideal and will cause people with busy timelines to completely miss retweets. Nobody is online 24x7, and if only the first retweet of an update is shown in a user's timeline, they will miss completely it if the first retweet happened several hours before they login and check their timeline. In other words, someone can retweet the same update while they are online and they still won't see it. From a Twitter-internal technical standpoint, new retweets are ideal because it eliminates a lot of duplication and accompanying processing and storage requirements. From a user's perspective, it is far from ideal. With old-style retweets, if I saw ten retweets of the same thing, I knew to check it out because obviously a lot of people felt it was something worth sharing with their followers. With the new retweets, I'm going to miss that completely. Even if I notice the first retweet, the retweeted by section may show only one or two people, and I won't know that the update was retweeted by twenty more people after I happened to look at it. In my irrelevant opinion, the new retweet feature is trying to fix something that was not broken. Dewald On Nov 17, 3:58 pm, Marcel Molina mar...@twitter.com wrote: Should appear as a new tweet with the time of the retweet, not the original tweet creation time. That assumes though that no one else has retweeted it to you yet. If someone else has then this additional retweet won't appear in your timelines except for the statuses/retweets/id resource that lists up to 100 retweets for a given tweet. Duplicates are collapsed out of the other timelines. On Tue, Nov 17, 2009 at 11:46 AM, Tim Haines tmhai...@gmail.com wrote: Hi guys, I'm wondering if anyone can clarify. The services I run often shown tweets that are several months old, and offer the RT button next to them. If someone clicks to RT the tweet, how does the tweet get presented to people that aren't following the original tweeter? Is it placed at the top of the timeline appearing as a new tweet, or is it placed at the time the original tweet was tweeted? i.e. months ago, so likely to never be seen? If it would be placed months ago, it makes RT pointless for older tweets, in which case I'll switch to 'classic mode' RT's. Tim. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] api.twitter.com SSL issue should be resolved now
After doing some righteous spelunking our ops team discovered a small misconfiguration that was very likely the culprit of the intermittent untrusted cert error people were getting when trying to hit api.twitter.com over SSL. This should be all fixed now. To those who reported the problem thank you. Please let us know if you still run into it. We don't think you will be we want to make sure it's totally fixed. Thanks to everyone who's been patient as we ferreted out this subtle problem. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: /statuses/retweets_of_me resource does not have the retweet_status element
I believe in this case the documentation is just incorrect. The status timeline of retweets_of_me is my original tweets that have been retweeted. I'll update the docs to reflect that. On Tue, Nov 10, 2009 at 7:11 PM, Michael Ivey (@ivey) michael.i...@gmail.com wrote: Marcel, et al I'm working on bringing our Retweet-commerce tools up to date with the new RTs, now that they're rolling out, and we've got an issue. /statuses/retweets_of_me is returning just the statuses, without a retweet_status element to tell me who did the retweet. Is this a doc issue, or a bug? -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: GET list members/subscribers - variant that returns ids only?
This has been brought up before and is on the list of things to implement. Thanks for the suggestion. On Wed, Nov 11, 2009 at 12:11 AM, Steve Farrell st...@farrell.org wrote: The social graph methods that return a list of ids are very simple and efficient. For example: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids. Are there plans for offering analogous queries for Lists? The existing functions for paging through user *objects* using cursors is considerably less efficient when you simply are looking for ids. Thanks! -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: GET list members/subscribers - variant that returns ids only?
Yup. Ids everywhere of everything! On Wed, Nov 11, 2009 at 11:23 AM, Steve Farrell st...@farrell.org wrote: That's great news! An analogous request: how about getting a set of list ids instead of list objects for subscriptions/memberships? On Nov 11, 11:18 am, Marcel Molina mar...@twitter.com wrote: This has been brought up before and is on the list of things to implement. Thanks for the suggestion. On Wed, Nov 11, 2009 at 12:11 AM, Steve Farrell st...@farrell.org wrote: The social graph methods that return a list of ids are very simple and efficient. For example:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids. Are there plans for offering analogous queries for Lists? The existing functions for paging through user *objects* using cursors is considerably less efficient when you simply are looking for ids. Thanks! -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Count for statuses from a list appears to do nothing
You can use the per_page parameter for this. I'll update the documentation. Should probably support count as well as an alias. On Mon, Nov 9, 2009 at 5:15 PM, Ryan Bigg radarliste...@gmail.com wrote: Specifying different count on the request appears to send back the same file: ryanb...@fp:mocra-web (master)$ wget http://api.twitter.com/1/drnic/ lists/mocra/statuses.json?callback=updateTwitter()count=100 --2009-11-10 11:13:41-- http://api.twitter.com/1/drnic/lists/mocra/statuses.json?callback=updateTwitter()count=100 Resolving api.twitter.com... 128.121.146.109 Connecting to api.twitter.com|128.121.146.109|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 24800 (24K) [application/json] Saving to: `statuses.json?callback=updateTwitter()count=100' 100% [==] 24,800 --.-K/s in 0.02s 2009-11-10 11:13:42 (1.56 MB/s) - `statuses.json?callback=updateTwitter ()count=100' saved [24800/24800] ryanb...@fp:mocra-web (master)$ wget http://api.twitter.com/1/drnic/ lists/mocra/statuses.json?callback=updateTwitter()count=5 --2009-11-10 11:13:51-- http://api.twitter.com/1/drnic/lists/mocra/statuses.json?callback=updateTwitter()count=5 Resolving api.twitter.com... 128.121.146.109 Connecting to api.twitter.com|128.121.146.109|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 24800 (24K) [application/json] Saving to: `statuses.json?callback=updateTwitter()count=5' 100% [==] 24,800 --.-K/s in 0.02s 2009-11-10 11:13:51 (1.37 MB/s) - `statuses.json?callback=updateTwitter ()count=5' saved [24800/24800] ryanb...@fp:mocra-web (master)$ Even though the API here says you can specify one: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-list-statuses?SearchFor=%3AListsp=5 What gives? -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: 500 ISE on List API Update?
Yes we've been made aware of this. It should be noted that the update sticks despite the 500 response. It's on our todo list of things to investigate. Thanks for reporting it. On Tue, Nov 10, 2009 at 9:48 AM, Aaron Brazell emmenset...@gmail.com wrote: I seem to be getting 500 Internal Server Errors on the List API for updating a list. Can anyone verify? Aaron Brazell CEO, Emmense Technologies Lead Editor, Technosailor.com Author, The WordPress Bible e: aa...@technosailor.com b: http://technosailor.com t: http://twitter.com/technosailor p: 443-455-1056Aaron Brazell web:: www.technosailor.com phone:: 410-608-6620 skype:: technosailor twitter:: @technosailor -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: direct messages to lists
That is indeed an interesting idea that we've been thinking about. The rules around who can send and receive DMs would continue to be enforced as normal, so for talking purposes, if you DMed a list, only those who follow you would receive it. On Tue, Nov 10, 2009 at 9:21 AM, Marcus Better mar...@better.se wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, have you considered adding a mechanism for sending a sort of direct message to a list? This would allow users to send targeted tweets to a list (provided the user is a member of the list). It could be incredibly useful. For example tweets on a specific topic could be targeted to a selected interest group, without bothering your general followers. Currently the only granularity provided is whole world (tweet) and single recipient (direct message), but this would allow new use cases, for example something similar to a mailing list. Cheers, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr5oQUACgkQXjXn6TzcAQk+PgCfemGcdxyqZZrg1tNsxTWhna39 gdAAoLJZHsM8yIqxzpHMp3XlYue2ODpz =ARYR -END PGP SIGNATURE- -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: direct messages to lists
As with all things, there will certainly be vectors for abuse. For every bad use case, there are just as many or more positive use cases. We'll certainly be thinking about many on both sides. Thanks for pointing out some of the potential hazards. On Tue, Nov 10, 2009 at 10:28 AM, Dewald Pretorius dpr...@gmail.com wrote: Marcel, How would that be different from sending bulk DMs - something I have been advised in the past is not something that Twitter condones. Here's the scenario. MarketerMario has 2,000 followers. He creates four lists and adds 500 of his followers to each list. Now he can send, with four simple clicks, his tweet whitening affiliate link to all his followers. Dewald On Nov 10, 2:19 pm, Marcel Molina mar...@twitter.com wrote: That is indeed an interesting idea that we've been thinking about. The rules around who can send and receive DMs would continue to be enforced as normal, so for talking purposes, if you DMed a list, only those who follow you would receive it. On Tue, Nov 10, 2009 at 9:21 AM, Marcus Better mar...@better.se wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, have you considered adding a mechanism for sending a sort of direct message to a list? This would allow users to send targeted tweets to a list (provided the user is a member of the list). It could be incredibly useful. For example tweets on a specific topic could be targeted to a selected interest group, without bothering your general followers. Currently the only granularity provided is whole world (tweet) and single recipient (direct message), but this would allow new use cases, for example something similar to a mailing list. Cheers, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org iEYEARECAAYFAkr5oQUACgkQXjXn6TzcAQk+PgCfemGcdxyqZZrg1tNsxTWhna39 gdAAoLJZHsM8yIqxzpHMp3XlYue2ODpz =ARYR -END PGP SIGNATURE- -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: 500 ISE on List API Update?
Worksforme: mar...@albatross:~TW% master ./bin/twurl /1/noradio/lists/1416.xml ?xml version=1.0 encoding=UTF-8? list id1416/id nametall people/name full_name@noradio/tall-people/full_name slugtall-people/slug subscriber_count3/subscriber_count member_count3/member_count uri/noradio/tall-people/uri modepublic/mode user etc ... On Tue, Nov 10, 2009 at 10:19 AM, Aaron Brazell emmenset...@gmail.com wrote: On Tue, Nov 10, 2009 at 1:16 PM, Marcel Molina mar...@twitter.com wrote: Yes we've been made aware of this. It should be noted that the update sticks despite the 500 response. It's on our todo list of things to investigate. Thanks for reporting it. Excellent. While we're at it, we're 404ing on the GET List ID API In case you didn't know that as well :) -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Blocking vs non-blocking list creation: list streams are different
Indeed something looks strange there. I've brought this to the attention of the team working on the lists backend. I'll let you know what they discover. On Mon, Nov 9, 2009 at 10:20 PM, Eric Gilbert eegilb...@gmail.com wrote: I'm developing an app that builds a few lists. Since it seems the only way to add users to lists is one id per call (please let me know if I'm mistaken), I experimented with populating the lists asynchronously. Both seem to build the list fine, and of course async is much faster. Here's the strange thing: although the lists created with each method have the same membership list, the lists streams are not the same. (Sync seems to be doing the right thing, but I haven't verified this rigorously.) For example, see http://twitter.com/eegilbert/right vs http://twitter.com/eegilbert/notsoright Strange. Cheers, Eric -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: direct messages to lists
But people who are added to MarketerMario's list won't get his list broadcasts unless they follow him. That's their opt-in. If they have followed him for whatever reason and decide they do *not* want his broadcasts, they can simply unfollow him. On Tue, Nov 10, 2009 at 10:46 AM, Dewald Pretorius dpr...@gmail.com wrote: Marcel, You can circumvent the issue by making the receiving of a DM that is sent to a list dependent on two triggers: a) You must follow the sender of the DM; and b) You must explicitly double opt-in to receive DMs that are sent to the list. Bona fide use cases will be able to acquire the double opt-ins from interested users, while most people will simply not opt-in when MarketerMario adds them to his list. Dewald On Nov 10, 2:34 pm, Marcel Molina mar...@twitter.com wrote: As with all things, there will certainly be vectors for abuse. For every bad use case, there are just as many or more positive use cases. We'll certainly be thinking about many on both sides. Thanks for pointing out some of the potential hazards. On Tue, Nov 10, 2009 at 10:28 AM, Dewald Pretorius dpr...@gmail.com wrote: Marcel, How would that be different from sending bulk DMs - something I have been advised in the past is not something that Twitter condones. Here's the scenario. MarketerMario has 2,000 followers. He creates four lists and adds 500 of his followers to each list. Now he can send, with four simple clicks, his tweet whitening affiliate link to all his followers. Dewald On Nov 10, 2:19 pm, Marcel Molina mar...@twitter.com wrote: That is indeed an interesting idea that we've been thinking about. The rules around who can send and receive DMs would continue to be enforced as normal, so for talking purposes, if you DMed a list, only those who follow you would receive it. On Tue, Nov 10, 2009 at 9:21 AM, Marcus Better mar...@better.se wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, have you considered adding a mechanism for sending a sort of direct message to a list? This would allow users to send targeted tweets to a list (provided the user is a member of the list). It could be incredibly useful. For example tweets on a specific topic could be targeted to a selected interest group, without bothering your general followers. Currently the only granularity provided is whole world (tweet) and single recipient (direct message), but this would allow new use cases, for example something similar to a mailing list. Cheers, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org iEYEARECAAYFAkr5oQUACgkQXjXn6TzcAQk+PgCfemGcdxyqZZrg1tNsxTWhna39 gdAAoLJZHsM8yIqxzpHMp3XlYue2ODpz =ARYR -END PGP SIGNATURE- -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: direct messages to lists
I'm not saying any of this is being implemented. I'm just responding in the abstract about the scenario you were proposing. On Tue, Nov 10, 2009 at 11:08 AM, Dewald Pretorius dpr...@gmail.com wrote: Marcel, You should talk to Jillian about this as well. I'm sure she will have a contrary opinion on the matter. Dewald On Nov 10, 2:51 pm, Marcel Molina mar...@twitter.com wrote: But people who are added to MarketerMario's list won't get his list broadcasts unless they follow him. That's their opt-in. If they have followed him for whatever reason and decide they do *not* want his broadcasts, they can simply unfollow him. On Tue, Nov 10, 2009 at 10:46 AM, Dewald Pretorius dpr...@gmail.com wrote: Marcel, You can circumvent the issue by making the receiving of a DM that is sent to a list dependent on two triggers: a) You must follow the sender of the DM; and b) You must explicitly double opt-in to receive DMs that are sent to the list. Bona fide use cases will be able to acquire the double opt-ins from interested users, while most people will simply not opt-in when MarketerMario adds them to his list. Dewald On Nov 10, 2:34 pm, Marcel Molina mar...@twitter.com wrote: As with all things, there will certainly be vectors for abuse. For every bad use case, there are just as many or more positive use cases. We'll certainly be thinking about many on both sides. Thanks for pointing out some of the potential hazards. On Tue, Nov 10, 2009 at 10:28 AM, Dewald Pretorius dpr...@gmail.com wrote: Marcel, How would that be different from sending bulk DMs - something I have been advised in the past is not something that Twitter condones. Here's the scenario. MarketerMario has 2,000 followers. He creates four lists and adds 500 of his followers to each list. Now he can send, with four simple clicks, his tweet whitening affiliate link to all his followers. Dewald On Nov 10, 2:19 pm, Marcel Molina mar...@twitter.com wrote: That is indeed an interesting idea that we've been thinking about. The rules around who can send and receive DMs would continue to be enforced as normal, so for talking purposes, if you DMed a list, only those who follow you would receive it. On Tue, Nov 10, 2009 at 9:21 AM, Marcus Better mar...@better.se wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, have you considered adding a mechanism for sending a sort of direct message to a list? This would allow users to send targeted tweets to a list (provided the user is a member of the list). It could be incredibly useful. For example tweets on a specific topic could be targeted to a selected interest group, without bothering your general followers. Currently the only granularity provided is whole world (tweet) and single recipient (direct message), but this would allow new use cases, for example something similar to a mailing list. Cheers, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org iEYEARECAAYFAkr5oQUACgkQXjXn6TzcAQk+PgCfemGcdxyqZZrg1tNsxTWhna39 gdAAoLJZHsM8yIqxzpHMp3XlYue2ODpz =ARYR -END PGP SIGNATURE- -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: can FOLLOW, but can't LEAVE
I've passed this along to our mobile team. Will update when I hear back from them. Thanks for reporting this. On Mon, Nov 9, 2009 at 2:24 PM, Cameron Kaiser spec...@floodgap.com wrote: I have users complaining that of the commands listed on http://help.twitter.com/forums/59008/entries/14020 they all still work right for status updates *except* LEAVE (FOLLOW *does* work). On my own testing, LEAVE just appears to do nothing. Did this break? -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Never explain, never apologise. -- John Arbuthnot Jackie Fisher -- -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: can FOLLOW, but can't LEAVE
The mobile team can't reproduce this problem. Several of them tried and LEAVE worked for all of them... On Mon, Nov 9, 2009 at 2:28 PM, Marcel Molina mar...@twitter.com wrote: I've passed this along to our mobile team. Will update when I hear back from them. Thanks for reporting this. On Mon, Nov 9, 2009 at 2:24 PM, Cameron Kaiser spec...@floodgap.com wrote: I have users complaining that of the commands listed on http://help.twitter.com/forums/59008/entries/14020 they all still work right for status updates *except* LEAVE (FOLLOW *does* work). On my own testing, LEAVE just appears to do nothing. Did this break? -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Never explain, never apologise. -- John Arbuthnot Jackie Fisher -- -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: /statuses/retweeted_to_me.xml?count=200 yields HTTP 500
Thanks for the report. Will try to recreate look into it. On Fri, Nov 6, 2009 at 12:35 AM, Dave Briccetti da...@davebsoft.com wrote: BY ME: http://twitter.com/statuses/retweeted_by_me.xml?count=200 works just fine. TO ME: /statuses/retweeted_to_me.xml?count=10 works fine. User dcbriccetti -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Question about versioning
We do not have plans to support minor versions initially. We're going to start with the simplest versioning scheme possible and then expand it to include minor versions when the need arises. So as of right now version 1 already exists, at http://api.twitter.com/1. As for whether it should be considered stable, I'd say it's very close to being so. I've been using it exclusively on my Twitter clients for several months. Since announcing it publicly a couple weeks ago the only reports of irregularities have been around server configuration (e.g. some requests over ssl getting an untrusted cert error and requests for gzipped responses not being configured correctly). As for the behavior of the API it should be 100% compatible with the non versioned twitter.com API. On Thu, Nov 5, 2009 at 7:36 AM, DeWitt Clinton dew...@unto.net wrote: Hi all, I'd like to sync the version numbers and release cycles of a few twitter libraries (python-twitter and java-twitter) up with the version of the Twitter API itself. I'll admit that I've fallen way behind on the maintenance of each, partly because the Twitter API itself is a moving target (not a bad thing, just hard to keep in sync with). What's the expected timing of when we can rely on a stable versioned endpoint for v1, v2, etc, and bleeding-edge API versions? In theory we'd do parallel releases on major/minor releases, and keep a dev branch open for the latest-and-greatest-and-beta-est version of the Twitter API. -DeWitt -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Draft of List API documentation
I think it should work for any request. Not sure though. Give it a try ;-) On Thu, Nov 5, 2009 at 5:48 AM, Paul Kinlan paul.kin...@gmail.com wrote: Can you confirm that _method=DELETE only works on POST's and not GET's? Paul 2009/11/3 Marcel Molina mar...@twitter.com A work around for environments that don't support the DELETE request method is, I believe, to pass a parameter called _method with the value DELETE. In other words _method=DELETE. On Mon, Nov 2, 2009 at 11:26 PM, wilfred yau wld991...@gmail.com wrote: It there any method to delete user from list other then using DELETE method? Since I am using Flex (but not Air) to develop third party Twitter Client, There are no way to call DELETE (which only GET and POST). So, will twitter provide POST or GET method API to delete? Thanks On Oct 16, 3:04 pm, Marcel Molina mar...@twitter.com wrote: Hey folks. As some of you have likely read we're starting to do some private beta testing of our new lists feature. We're not quite ready to open it up to everyone but we've made some headway on the API and wanted to share some details of what we've got so far. There are a handful of things on our todo lists so don't consider this signed and sealed just yet. You may notice this API is a bit of a departure from the rest of the API. It's a bit more, errr, REST than the rest. First off, here's the current payload for alist: ?xml version=1.0 encoding=UTF-8? list id1416/id nametall people/name full_name@noradio/tall-people/full_name slugtall-people/slug subscriber_count0/subscriber_count member_count3/member_count uri/noradio/tall-people/uri modepublic/mode user id3191321/id nameMarcel Molina/name screen_namenoradio/screen_name locationSan Francisco, CA/location descriptionEngineer at Twitter on the @twitterapi team, obsessed with rock climbing amp; running. In a past life I was a member of the Rails Core team./description profile_image_urlhttp://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_no.../profile_image_url urlhttp://project.ioni.st/url protectedfalse/protected followers_count40059/followers_count profile_background_color9AE4E8/profile_background_color profile_text_color33/profile_text_color profile_link_color0084B4/profile_link_color profile_sidebar_fill_colorDDFFCC/profile_sidebar_fill_color profile_sidebar_border_colorBDDCAD/profile_sidebar_border_color friends_count354/friends_count created_atMon Apr 02 07:47:28 + 2007/created_at favourites_count131/favourites_count utc_offset-28800/utc_offset time_zonePacific Time (US amp; Canada)/time_zone profile_background_image_urlhttp://a1.twimg.com/profile_background_images/18156348/jessica_tiled/profile_background_image_url profile_background_tiletrue/profile_background_tile statuses_count3472/statuses_count notificationsfalse/notifications geo_enabledtrue/geo_enabled verifiedfalse/verified followingfalse/following /user /list === Lists === POST '/:user/lists.:format' Creates a newlistfor the authenticated user. Parameters: * name: the name of thelist. (required) * mode: whether yourlistis public of private. Values can be 'public' or 'private'. Public by default if not specified. (optional) Usage notes: :user in the url should be the screen name of the user making the request to create thelist Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -d name=tall peoplemode=privatehttp://twitter.com/noradio/lists.xml POST/PUT '/:user/lists/:list_slug.:format' Updates the specifiedlist. Takes the same parameters as the create resource at POST '/:user/lists.:format' (:name and :mode). Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -d name=giantsmode=publichttp://twitter.com/noradio/lists/tall-people.xml GET '/:user/lists.:format' Lists your lists. Supported format: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists.xml GET '/:user/lists/memberships.:format'Listthe lists the specified user has been added to. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/memberships.xml DELETE '/:user/lists/:list_slug.:format' Delete the specifiedlistowned by the authenticated user. Parameters: * list_slug: the slug of thelistyou want to delete. (required) Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -X DELETEhttp://twitter.com/noradio/lists/tall-people.xml GET '/:users/lists/:list_slug/statuses.:format' Show tweet timeline for members of the specifiedlist. Parameters: * list_slug: the slug of thelistyou want the member tweet timeline of. (required) * next/previous_cursor: used to page through results
[twitter-dev] Re: Draft of List API documentation
Status timelines paginate with the page parameters. Social graph resources such as the members in a list use the cursor parameters. We're looking to rationalize all this as we move to new systems but for now there are different interfaces. You use the same mechanisms for the list statuses timeline as you do for all other status timelines. On Thu, Nov 5, 2009 at 7:05 AM, Milen mi...@thecosmicmachine.com wrote: I think that all methods which refer to lists should use the id, not the slug. As people have mentioned, the slug can change, so in order to reliably delete a list, you will have to fetch its slug and then issue a delete (or you risk getting an error as the slug might have changed in the meantime). I also tried to page through the statuses in a list but it seemed that: - next_cursor / previous_cursor had no effect on what was returned - cursor=-1 or anything else didn't have an effect Can anyone shed some light on how we're supposed to do paging? Thanks, M On Oct 16, 7:04 am, Marcel Molina mar...@twitter.com wrote: GET '/:users/lists/:list_slug/statuses.:format' Show tweet timeline for members of the specified list. Parameters: * list_slug: the slug of the list you want the member tweet timeline of. (required) * next/previous_cursor: used to page through results (optional) Supported formats: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/tall-people/statuses.xml -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Draft of List API documentation
We will support specifying a list by both id and slug indefinitely. Though we recognize the short comings of finding by slug since they are prone to changing, there are use cases where finding by slug is a lot more convenient. So we'll be supporting both. You never *have* to search by slug :-) On Thu, Nov 5, 2009 at 7:05 AM, Milen mi...@thecosmicmachine.com wrote: I think that all methods which refer to lists should use the id, not the slug. As people have mentioned, the slug can change, so in order to reliably delete a list, you will have to fetch its slug and then issue a delete (or you risk getting an error as the slug might have changed in the meantime). I also tried to page through the statuses in a list but it seemed that: - next_cursor / previous_cursor had no effect on what was returned - cursor=-1 or anything else didn't have an effect Can anyone shed some light on how we're supposed to do paging? Thanks, M On Oct 16, 7:04 am, Marcel Molina mar...@twitter.com wrote: GET '/:users/lists/:list_slug/statuses.:format' Show tweet timeline for members of the specified list. Parameters: * list_slug: the slug of the list you want the member tweet timeline of. (required) * next/previous_cursor: used to page through results (optional) Supported formats: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/tall-people/statuses.xml -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Is image shrinking broken?
I've passed this issue along to the team that owns the image resizing code to see if they have any insights into what the issue might be. On Mon, Nov 2, 2009 at 9:25 PM, TCI ticoconid...@gmail.com wrote: I am noticing an increase in the number of avatar images which do not get shrinked in the smaller versions. It is most noticeable in the twitter.com homepage as the images load very slowly from top to bottom. How are your clients handling this? In my case I am assuming the shrinking is working and therefore my page load times are being affected. Example: http://a3.twimg.com/profile_images/506101471/Copy__2__of_Francesca__4__bigger.jpg http://a3.twimg.com/profile_images/506101471/Copy__2__of_Francesca__4__normal.jpg http://a3.twimg.com/profile_images/506101471/Copy__2__of_Francesca__4__mini.jpg are all the same... -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Background images on a0.twimg.com giving access denied
To follow up I've been told that this is the most critical bug they
are working on right now. So it's being worked on. I'll pass along
updates as provided.
On Wed, Nov 4, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote:
Thanks for reporting this. I've forwarded this to the team responsible
for the S3 uploading.
On Wed, Nov 4, 2009 at 10:28 AM, Kevin kevinh...@gmail.com wrote:
We are uploading Twitter backgrounds via the API. We noticed today new
attempts to upload seem to be successful, but the profiles show no
background image. Looking at the page source, it shows a new
background image URL:
background: ... url('http://a0.twimg.com/profile_background_images/
bg12573586264055.jpg') ...;
However, opening that URL returns an error:
?xml version=1.0 encoding=UTF-8?
ErrorCodeAccessDenied/CodeMessageAccess Denied/
MessageRequestId20FB3BC5AEC2A2D5/RequestIdHostIdKheAYU8E/puKx
+qm5jtF9YeLLfc/NHcoCr6q2iOWZy2OR3tbtouA3Fo5aTrHUrZn/HostId/Error
It would appear Twitter is not adding the S3 access key query string
to these background image URLs, or the images are being put into S3 as
private items.
Hope to see a fix soon.
Regards,
Kevin Hunt
Bubble Fusion Labs
--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio
--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio
[twitter-dev] Re: api.twitter.com not returning compressed data
We've confirmed this and reported it to our operations team. We've identified the problem and are actively fixing it. Thanks for the detailed report. I'll let you know when the gzip compression is restored. On Thu, Nov 5, 2009 at 7:19 PM, Jason Diller jdil...@gmail.com wrote: API calls to http://twitter.com/ with Accept-Encoding:gzip in the headers are returning compressed data, while calls to http://api.twitter.com/1/ with the same headers do not. You can demonstrate this with cUrl: curl --basic -u user:pass --header Accept-Encoding:gzip, deflate http://api.twitter.com/1/statuses/friends_timeline.json vs. curl --basic -u user:pass --header Accept-Encoding:gzip, deflate http://twitter.com/statuses/friends_timeline.json In the second example, you will get garbled response indicating that the data is compressed, whereas in the first you will get clear text. (Note: if you use --compress instead of --header then cUrl will decompress the response so you'll have to use Wireshark or some other network sniffer to see the raw data). We tracked this down because one of our users in Europe reported a big perf hit after we switched to the versioned endpoint. (see http://code.google.com/p/tweetsharp/issues/detail?id=104) I hope this isn't by design. Jason Diller Tweetsharp Contributor -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Getting user info from REST interface using name and not screen name
There is no API for that at the moment. We're developing an API for people search though. On Thu, Nov 5, 2009 at 6:38 PM, Kripashankar krip...@gmail.com wrote: Hi, I am developing a small prototype and would like to know the following. 1. How can I get info about a user given only the name and not screen name ? Example: http://twitter.com/users/show.xml?screen_name=aplusk gives me info about ashton kutcher but let's say I don't know the screen name but only know the name Ashton Kutcher. How can I get the corresponding screen name and id, or the user info with just the name ? The api http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show doesn't seem to take name as a parameter. BTW, I noticed two user info http://twitter.com/users/show.xml?screen_name=aplusk http://twitter.com/users/show.xml?screen_name=ashtonkutcher So I am not sure which is the right one as well for Ashton Kutcher. Any help much appreciated. Thanks! -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: api.twitter.com not returning compressed data
The configuration has been fixed. The configuration updates should be pushed out to all servers tomorrow morning PST. On Thu, Nov 5, 2009 at 8:20 PM, Marcel Molina mar...@twitter.com wrote: We've confirmed this and reported it to our operations team. We've identified the problem and are actively fixing it. Thanks for the detailed report. I'll let you know when the gzip compression is restored. On Thu, Nov 5, 2009 at 7:19 PM, Jason Diller jdil...@gmail.com wrote: API calls to http://twitter.com/ with Accept-Encoding:gzip in the headers are returning compressed data, while calls to http://api.twitter.com/1/ with the same headers do not. You can demonstrate this with cUrl: curl --basic -u user:pass --header Accept-Encoding:gzip, deflate http://api.twitter.com/1/statuses/friends_timeline.json vs. curl --basic -u user:pass --header Accept-Encoding:gzip, deflate http://twitter.com/statuses/friends_timeline.json In the second example, you will get garbled response indicating that the data is compressed, whereas in the first you will get clear text. (Note: if you use --compress instead of --header then cUrl will decompress the response so you'll have to use Wireshark or some other network sniffer to see the raw data). We tracked this down because one of our users in Europe reported a big perf hit after we switched to the versioned endpoint. (see http://code.google.com/p/tweetsharp/issues/detail?id=104) I hope this isn't by design. Jason Diller Tweetsharp Contributor -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: RSS support for Lists
We will be supporting atom for the statuses timeline of a list soon. On Wed, Nov 4, 2009 at 6:17 AM, alexkingorg alexking...@gmail.com wrote: [Sorry if this has been covered, I searched for a while before posting.] According to the documentation and my initial testing, there does not appear to be support for receiving data from a List in RSS format (only json and xml). Is there a reason why this hasn't been added or was it just not high enough priority and will get added at some point in the future? If you were waiting for someone to request it, I'm happy to fill that role. :) Thanks, --Alex -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Draft of List API documentation
We plan to support this. It's on the todo list. Thanks for the suggestion. On Tue, Nov 3, 2009 at 8:38 PM, Damon Clinkscales sca...@pobox.com wrote: On Fri, Oct 16, 2009 at 1:04 AM, Marcel Molina mar...@twitter.com wrote: Hey folks. As some of you have likely read we're starting to do some private beta testing of our new lists feature. We're not quite ready to open it up to everyone but we've made some headway on the API and wanted to share some details of what we've got so far. There are a handful of things on our todo lists so don't consider this signed and sealed just yet. Marcel, It would be nice if we could pass in either the user_id or the screen_name, wherever you are currently requiring a Twitter user id. This would be consistent with the rest of the REST API (and quite useful, saving an extra call). Thanks, -damon -- http://twitter.com/damon -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Background images on a0.twimg.com giving access denied
Thanks for reporting this. I've forwarded this to the team responsible
for the S3 uploading.
On Wed, Nov 4, 2009 at 10:28 AM, Kevin kevinh...@gmail.com wrote:
We are uploading Twitter backgrounds via the API. We noticed today new
attempts to upload seem to be successful, but the profiles show no
background image. Looking at the page source, it shows a new
background image URL:
background: ... url('http://a0.twimg.com/profile_background_images/
bg12573586264055.jpg') ...;
However, opening that URL returns an error:
?xml version=1.0 encoding=UTF-8?
ErrorCodeAccessDenied/CodeMessageAccess Denied/
MessageRequestId20FB3BC5AEC2A2D5/RequestIdHostIdKheAYU8E/puKx
+qm5jtF9YeLLfc/NHcoCr6q2iOWZy2OR3tbtouA3Fo5aTrHUrZn/HostId/Error
It would appear Twitter is not adding the S3 access key query string
to these background image URLs, or the images are being put into S3 as
private items.
Hope to see a fix soon.
Regards,
Kevin Hunt
Bubble Fusion Labs
--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio
[twitter-dev] Re: Draft of List API documentation
A work around for environments that don't support the DELETE request method is, I believe, to pass a parameter called _method with the value DELETE. In other words _method=DELETE. On Mon, Nov 2, 2009 at 11:26 PM, wilfred yau wld991...@gmail.com wrote: It there any method to delete user from list other then using DELETE method? Since I am using Flex (but not Air) to develop third party Twitter Client, There are no way to call DELETE (which only GET and POST). So, will twitter provide POST or GET method API to delete? Thanks On Oct 16, 3:04 pm, Marcel Molina mar...@twitter.com wrote: Hey folks. As some of you have likely read we're starting to do some private beta testing of our new lists feature. We're not quite ready to open it up to everyone but we've made some headway on the API and wanted to share some details of what we've got so far. There are a handful of things on our todo lists so don't consider this signed and sealed just yet. You may notice this API is a bit of a departure from the rest of the API. It's a bit more, errr, REST than the rest. First off, here's the current payload for alist: ?xml version=1.0 encoding=UTF-8? list id1416/id nametall people/name full_name@noradio/tall-people/full_name slugtall-people/slug subscriber_count0/subscriber_count member_count3/member_count uri/noradio/tall-people/uri modepublic/mode user id3191321/id nameMarcel Molina/name screen_namenoradio/screen_name locationSan Francisco, CA/location descriptionEngineer at Twitter on the @twitterapi team, obsessed with rock climbing amp; running. In a past life I was a member of the Rails Core team./description profile_image_urlhttp://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_no.../profile_image_url urlhttp://project.ioni.st/url protectedfalse/protected followers_count40059/followers_count profile_background_color9AE4E8/profile_background_color profile_text_color33/profile_text_color profile_link_color0084B4/profile_link_color profile_sidebar_fill_colorDDFFCC/profile_sidebar_fill_color profile_sidebar_border_colorBDDCAD/profile_sidebar_border_color friends_count354/friends_count created_atMon Apr 02 07:47:28 + 2007/created_at favourites_count131/favourites_count utc_offset-28800/utc_offset time_zonePacific Time (US amp; Canada)/time_zone profile_background_image_urlhttp://a1.twimg.com/profile_background_images/18156348/jessica_tiled/profile_background_image_url profile_background_tiletrue/profile_background_tile statuses_count3472/statuses_count notificationsfalse/notifications geo_enabledtrue/geo_enabled verifiedfalse/verified followingfalse/following /user /list === Lists === POST '/:user/lists.:format' Creates a newlistfor the authenticated user. Parameters: * name: the name of thelist. (required) * mode: whether yourlistis public of private. Values can be 'public' or 'private'. Public by default if not specified. (optional) Usage notes: :user in the url should be the screen name of the user making the request to create thelist Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -d name=tall peoplemode=privatehttp://twitter.com/noradio/lists.xml POST/PUT '/:user/lists/:list_slug.:format' Updates the specifiedlist. Takes the same parameters as the create resource at POST '/:user/lists.:format' (:name and :mode). Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -d name=giantsmode=publichttp://twitter.com/noradio/lists/tall-people.xml GET '/:user/lists.:format' Lists your lists. Supported format: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists.xml GET '/:user/lists/memberships.:format'Listthe lists the specified user has been added to. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/memberships.xml DELETE '/:user/lists/:list_slug.:format' Delete the specifiedlistowned by the authenticated user. Parameters: * list_slug: the slug of thelistyou want to delete. (required) Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -X DELETEhttp://twitter.com/noradio/lists/tall-people.xml GET '/:users/lists/:list_slug/statuses.:format' Show tweet timeline for members of the specifiedlist. Parameters: * list_slug: the slug of thelistyou want the member tweet timeline of. (required) * next/previous_cursor: used to page through results (optional) Supported formats: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/tall-people/statuses.xml GET '/:users/lists/:list_slug.:format' Show a specificlistyou can use the new resource. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/tall-people.xml ===Listmembers === POST '/:user/:list_slug/members.:format
[twitter-dev] Re: List API : statuses timeline and count parameter
You can use all the same parameters as are available in the other status timeline resources (e.g. max_id, count, since_id, etc). On Tue, Nov 3, 2009 at 4:07 PM, stephane stephane.philipa...@gmail.com wrote: Hi guys ! Is there a way (or planned method) to get more than 20 statuses per list timeline API call ? apparently there is no equivalent to the count parameter. Best, Stephane Philipakis @sphilipakis www.twazzup.com -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: List API : statuses timeline and count parameter
Oh. I've realized that all the options *except* for count are supported. Fixing that now. Should be deployed to production in the next day or so. Thanks for reporting this. On Tue, Nov 3, 2009 at 5:01 PM, Marcel Molina mar...@twitter.com wrote: You can use all the same parameters as are available in the other status timeline resources (e.g. max_id, count, since_id, etc). On Tue, Nov 3, 2009 at 4:07 PM, stephane stephane.philipa...@gmail.com wrote: Hi guys ! Is there a way (or planned method) to get more than 20 statuses per list timeline API call ? apparently there is no equivalent to the count parameter. Best, Stephane Philipakis @sphilipakis www.twazzup.com -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Lists API
It's available to all developers and has been since last Thursday. There are still some tweaks to be made but everything that works now should continue to be supported along side the changes and additions that will be introduced. On Mon, Nov 2, 2009 at 9:48 AM, Michael Steuer mste...@gmail.com wrote: With all the discussions on this mailing list about the Lists API, can someone please confirm, is the API now available to all developers or all of you in some sort of preferred position? Thanks, Michael. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Truncated URLs
I believe in that case the url is just truncated and gone. I believe this only works when shortening it with bit.ly still wouldn't make the tweet fewer than 140 characters. Though it seems unfortunate to lose the url, in a sense you aren't missing data because *no one* gets that url so ultimately it doesn't really exist :) I'd imagine this is fairly rare, yes? I'd recommend just giving up and skipping the tweet if the url isn't fully formed. On Mon, Nov 2, 2009 at 6:51 AM, Adam Green a...@vibemetrix.com wrote: I'm extracting URLs from tweets, and some of them are truncated at the end of a tweet. The URL ends up as something like http://domain... I can't find anything in the API that will let me get the full URL, so I assume it is lost. Is this correct, or is there some trick to get back the entire URL before truncation? -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Subscribed Lists
There is, in a sense, an API for resolving a list id by passing in a slug. It's the show resource for a list. You'll either get a 404 (which means the slug no longer exist) or you'll get the list payload which will include the id. On Sun, Nov 1, 2009 at 11:29 PM, Rich rhyl...@gmail.com wrote: Using ID only for me is fine, except in the case we mention. If there was a REST api to find a list ID based on a slug then it would mean we could still resolve @screen_name/list_name links otherwise we wouldn't be able to replicate it, except by brute force which would use yet more API calls. On Nov 1, 6:14 pm, Marcel Molina mar...@twitter.com wrote: Resolving a @screen_name/list_name reference in a tweet is a compelling argument for making the url parameter polymorphic and not deprecating the use of slugs. I will cogitate. On Sun, Nov 1, 2009 at 10:09 AM, kaiser.ma...@gmail.com wrote: I have to second Rich on this - ID-only is flawed, as twitter supports hotlinking lists by name (@username/slug) in tweets, and links that to the list page. If clients want to offer the same behavior, this is not possible if the API only supports IDs (or would require a potentially large number of additional requests to get the user's lists and page through them to find the one mentioned). Marco -Original Message- From: Marcel Molina mar...@twitter.com Date: Sun, 1 Nov 2009 10:02:31 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Subscribed Lists Currently it's still slug. It hasn't been updated yet. When it is updated it will for some period of transition accept a slug or an id but eventually support for the slug in the url will be removed entirely. On Sun, Nov 1, 2009 at 2:14 AM, Rich rhyl...@gmail.com wrote: Can we get some form of confirmation on the list slug/id issue. At the moment calling by ID doesn't work anyway so it's only using the slug. My preference would be to allow either (in a similar way to the other REST api's where you can use user id or screenName) On Oct 31, 10:04 pm, twittelator and...@stone.com wrote: :user/lists/subscriptions.:format gets the lists that the user has subscribed to. Andrew Stone Twitter / @twittelatorhttp://www.stone.com got iPhone? http://tinyurl.com/twitpro http://tinyurl.com/intentionizer http://tinyurl.com/gesture-buy http://tinyurl.com/igraffiti http://tinyurl.com/talkingpics http://tinyurl.com/mobilemix http://tinyurl.com/soundbite http://tinyurl.com/icreated http://tinyurl.com/pulsar-app On Oct 30, 5:00 am, David Neubauer davidneubauer.gro...@gmail.com wrote: Has any figured out how to get a the lists I'm subscribed to. I didn't realize how much I'd want this part of it. Please say it's coming... -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Jeremy Felt Sent: Thursday, October 29, 2009 8:16 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names) It appears that user/lists.xml only shows lists that are created by the user and not those that they follow. Any change coming to that or am I missing a way to see all lists that a user follows? Thanks, Jeremy On Oct 28, 3:00 pm, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships
[twitter-dev] Re: Lists API
You may (until further notice) ;-) On Mon, Nov 2, 2009 at 10:12 AM, kaiser.ma...@gmail.com wrote: Can I translate that into 'the current URL to get a list using the slug will not be deprecated'? Marco -Original Message- From: Marcel Molina mar...@twitter.com Date: Mon, 2 Nov 2009 10:05:03 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Lists API It's available to all developers and has been since last Thursday. There are still some tweaks to be made but everything that works now should continue to be supported along side the changes and additions that will be introduced. On Mon, Nov 2, 2009 at 9:48 AM, Michael Steuer mste...@gmail.com wrote: With all the discussions on this mailing list about the Lists API, can someone please confirm, is the API now available to all developers or all of you in some sort of preferred position? Thanks, Michael. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: update_delivery_device method
Please file a bug about this on our issue tracker if you haven't already: http://code.google.com/p/twitter-api/issues/list Thanks. On Wed, Oct 28, 2009 at 11:55 PM, DustyReagan dustyrea...@gmail.com wrote: I was playing around with the account/update_delivery_device method. It seems to behave like this: device=sms:im - Does nothing device=none - Turns device updates off Neither sms or im turn device updates back on. Are there any plans for this method to be updated or deprecated? -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Subscribed Lists
Both will be allowed. On Mon, Nov 2, 2009 at 1:34 PM, Rich rhyl...@gmail.com wrote: Thanks for that Marcel, well if it's decided to completely abandon slugs I'll have to go down that route. Any idea on whether both call types will be allowed yet? Obviously the main lookups will are quick to switch between, just this @screen_name/list_name that'll take more work if we can't use the slug. On Nov 2, 6:12 pm, Marcel Molina mar...@twitter.com wrote: There is, in a sense, an API for resolving a list id by passing in a slug. It's the show resource for a list. You'll either get a 404 (which means the slug no longer exist) or you'll get the list payload which will include the id. On Sun, Nov 1, 2009 at 11:29 PM, Rich rhyl...@gmail.com wrote: Using ID only for me is fine, except in the case we mention. If there was a REST api to find a list ID based on a slug then it would mean we could still resolve @screen_name/list_name links otherwise we wouldn't be able to replicate it, except by brute force which would use yet more API calls. On Nov 1, 6:14 pm, Marcel Molina mar...@twitter.com wrote: Resolving a @screen_name/list_name reference in a tweet is a compelling argument for making the url parameter polymorphic and not deprecating the use of slugs. I will cogitate. On Sun, Nov 1, 2009 at 10:09 AM, kaiser.ma...@gmail.com wrote: I have to second Rich on this - ID-only is flawed, as twitter supports hotlinking lists by name (@username/slug) in tweets, and links that to the list page. If clients want to offer the same behavior, this is not possible if the API only supports IDs (or would require a potentially large number of additional requests to get the user's lists and page through them to find the one mentioned). Marco -Original Message- From: Marcel Molina mar...@twitter.com Date: Sun, 1 Nov 2009 10:02:31 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Subscribed Lists Currently it's still slug. It hasn't been updated yet. When it is updated it will for some period of transition accept a slug or an id but eventually support for the slug in the url will be removed entirely. On Sun, Nov 1, 2009 at 2:14 AM, Rich rhyl...@gmail.com wrote: Can we get some form of confirmation on the list slug/id issue. At the moment calling by ID doesn't work anyway so it's only using the slug. My preference would be to allow either (in a similar way to the other REST api's where you can use user id or screenName) On Oct 31, 10:04 pm, twittelator and...@stone.com wrote: :user/lists/subscriptions.:format gets the lists that the user has subscribed to. Andrew Stone Twitter / @twittelatorhttp://www.stone.com got iPhone? http://tinyurl.com/twitpro http://tinyurl.com/intentionizer http://tinyurl.com/gesture-buy http://tinyurl.com/igraffiti http://tinyurl.com/talkingpics http://tinyurl.com/mobilemix http://tinyurl.com/soundbite http://tinyurl.com/icreated http://tinyurl.com/pulsar-app On Oct 30, 5:00 am, David Neubauer davidneubauer.gro...@gmail.com wrote: Has any figured out how to get a the lists I'm subscribed to. I didn't realize how much I'd want this part of it. Please say it's coming... -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Jeremy Felt Sent: Thursday, October 29, 2009 8:16 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names) It appears that user/lists.xml only shows lists that are created by the user and not those that they follow. Any change coming to that or am I missing a way to see all lists that a user follows? Thanks, Jeremy On Oct 28, 3:00 pm, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't
[twitter-dev] Re: Subscribed Lists
Currently it's still slug. It hasn't been updated yet. When it is updated it will for some period of transition accept a slug or an id but eventually support for the slug in the url will be removed entirely. On Sun, Nov 1, 2009 at 2:14 AM, Rich rhyl...@gmail.com wrote: Can we get some form of confirmation on the list slug/id issue. At the moment calling by ID doesn't work anyway so it's only using the slug. My preference would be to allow either (in a similar way to the other REST api's where you can use user id or screenName) On Oct 31, 10:04 pm, twittelator and...@stone.com wrote: :user/lists/subscriptions.:format gets the lists that the user has subscribed to. Andrew Stone Twitter / @twittelatorhttp://www.stone.com got iPhone? http://tinyurl.com/twitpro http://tinyurl.com/intentionizer http://tinyurl.com/gesture-buy http://tinyurl.com/igraffiti http://tinyurl.com/talkingpics http://tinyurl.com/mobilemix http://tinyurl.com/soundbite http://tinyurl.com/icreated http://tinyurl.com/pulsar-app On Oct 30, 5:00 am, David Neubauer davidneubauer.gro...@gmail.com wrote: Has any figured out how to get a the lists I'm subscribed to. I didn't realize how much I'd want this part of it. Please say it's coming... -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Jeremy Felt Sent: Thursday, October 29, 2009 8:16 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names) It appears that user/lists.xml only shows lists that are created by the user and not those that they follow. Any change coming to that or am I missing a way to see all lists that a user follows? Thanks, Jeremy On Oct 28, 3:00 pm, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: how to create list of lists
This is probably confusion arising from something I wrote in a previous email. When I said list of list I meant the payload of the response body had zero or more list elements in it, therefore a list of lists. There is no way to create lists of lists in the sense that you are talking about. On Sat, Oct 31, 2009 at 7:13 AM, Ravi ravikapoor...@gmail.com wrote: The new api talks about list of lists. I do not see how to add a list to another list. Whenever I follow a list, my main account follows it, not my list. On a side note, I was playing with the API yesterday and somehow a list I created shows up twice under Lists you follow. I guess a bug somewhere. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Subscribed Lists
Resolving a @screen_name/list_name reference in a tweet is a compelling argument for making the url parameter polymorphic and not deprecating the use of slugs. I will cogitate. On Sun, Nov 1, 2009 at 10:09 AM, kaiser.ma...@gmail.com wrote: I have to second Rich on this - ID-only is flawed, as twitter supports hotlinking lists by name (@username/slug) in tweets, and links that to the list page. If clients want to offer the same behavior, this is not possible if the API only supports IDs (or would require a potentially large number of additional requests to get the user's lists and page through them to find the one mentioned). Marco -Original Message- From: Marcel Molina mar...@twitter.com Date: Sun, 1 Nov 2009 10:02:31 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Subscribed Lists Currently it's still slug. It hasn't been updated yet. When it is updated it will for some period of transition accept a slug or an id but eventually support for the slug in the url will be removed entirely. On Sun, Nov 1, 2009 at 2:14 AM, Rich rhyl...@gmail.com wrote: Can we get some form of confirmation on the list slug/id issue. At the moment calling by ID doesn't work anyway so it's only using the slug. My preference would be to allow either (in a similar way to the other REST api's where you can use user id or screenName) On Oct 31, 10:04 pm, twittelator and...@stone.com wrote: :user/lists/subscriptions.:format gets the lists that the user has subscribed to. Andrew Stone Twitter / @twittelatorhttp://www.stone.com got iPhone? http://tinyurl.com/twitpro http://tinyurl.com/intentionizer http://tinyurl.com/gesture-buy http://tinyurl.com/igraffiti http://tinyurl.com/talkingpics http://tinyurl.com/mobilemix http://tinyurl.com/soundbite http://tinyurl.com/icreated http://tinyurl.com/pulsar-app On Oct 30, 5:00 am, David Neubauer davidneubauer.gro...@gmail.com wrote: Has any figured out how to get a the lists I'm subscribed to. I didn't realize how much I'd want this part of it. Please say it's coming... -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Jeremy Felt Sent: Thursday, October 29, 2009 8:16 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names) It appears that user/lists.xml only shows lists that are created by the user and not those that they follow. Any change coming to that or am I missing a way to see all lists that a user follows? Thanks, Jeremy On Oct 28, 3:00 pm, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
Answers inline: On Wed, Oct 28, 2009 at 1:14 PM, Tim Haines tmhai...@gmail.com wrote: Marcel, Great changes. A couple of questions: - How long can a list description be? 160 :-) - A title can only be 15 chars - will that remain unchanged? Unchanged. - Will there be a little overlap where memberships and subscribers will still work while people migrate to followers/following? Yeah. There will be overlap for some period of time for those who might need to transition. It would be awesome if there was a way to retrieve all member ids and a separate call for subscriber ids - cursored if necessary. Right, I'll add that to the list of things to consider :-) Also, filed an edge case bug around list error messages a couple of days ago. http://code.google.com/p/twitter-api/issues/detail?id=1145sort=-openedcolspec=ID%20Stars%20Type%20Status%20Priority%20Owner%20Summary%20Opened%20Modified%20Component Thanks. Cheers, Tim. On Oct 29, 9:00 am, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
Real soon now. We appreciate everyone's patience while we gradually ramp up traffic to lists to ensure we've got all our ducks in a row. On Wed, Oct 28, 2009 at 2:53 PM, Rich rhyl...@gmail.com wrote: +1 to this Any news on when the rest of us devs can get access to this to work on our apps? On Oct 28, 8:11 pm, Jesse Stay jesses...@gmail.com wrote: Maybe a little more appropriate to post this to a private list (no pun intended) for beta users? I admit I feel a little jealous every time I see one of these updates, unless there's some way to get into the beta. Thanks, Jesse On Wed, Oct 28, 2009 at 2:00 PM, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
The cursors are for lists of lists and lists of users followed by/following lists. The statuses timeline for a given list takes all the same options you'd expect to manage status timelines. On Wed, Oct 28, 2009 at 5:43 PM, Naveen knig...@gmail.com wrote: How does one keep a list up to date for a client without the concept of since_id, like we have for the timeline methods? I look at a lists as just a different timeline (granted one filtered to specific users), but that is how I would expect to view them in a client. From my understanding of cursors, on each request we have to start at -1 (to start paging) and page until we find an id that we already have locally. While this will work, it has a high probability of always over requesting data.. So if I have a list with two people in it, and they only tweet once a week, when I poll for updates of this list (say every 30min) the data is going to be the same most of the time(last 100 messages that these two people post). This seems like a waste of bandwidth for Twitter and us.. Some may argue that bandwidth is cheap, but it really is not on mobile devices. Some carriers charge per kb, but even on unlimited plans every byte transferred translates to additional battery drain.. Is there some concept of the cursor that I am not understanding that will allow us to also filter based on something like since_id? So we want to get messages newer than we already have and notify the user that the list has something new to display. Thanks to anyone who can clarify if I am misunderstanding something. --Naveen On Oct 28, 6:14 pm, Marcel Molina mar...@twitter.com wrote: Real soon now. We appreciate everyone's patience while we gradually ramp up traffic to lists to ensure we've got all our ducks in a row. On Wed, Oct 28, 2009 at 2:53 PM, Rich rhyl...@gmail.com wrote: +1 to this Any news on when the rest of us devs can get access to this to work on our apps? On Oct 28, 8:11 pm, Jesse Stay jesses...@gmail.com wrote: Maybe a little more appropriate to post this to a private list (no pun intended) for beta users? I admit I feel a little jealous every time I see one of these updates, unless there's some way to get into the beta. Thanks, Jesse On Wed, Oct 28, 2009 at 2:00 PM, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Not cool to RT a protected tweet
Protected tweets will not be retweetable. On Thu, Oct 22, 2009 at 11:42 AM, Tim Haines tmhai...@gmail.com wrote: Hey guys, @ev: It's not cool to RT a protected tweet http://twitter.com/ev/status/4955618846 Will the new RT api disallow you from RT'ing protected tweets? I think this would be a good move. Tim. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Draft of List API documentation
There are plans to expose a description field eventually. On Wed, Oct 21, 2009 at 9:59 AM, nipunj nip...@gmail.com wrote: Hey Marcel, I expect there were many things cut in Lists v1,... but, that said, I am surprised that Title is essentially the only attribute on the List object that informs the consumer what a Public List is intended to actually represent. There's no bio analog. IMO, this lack of explicit descriptive attributes hamstrings Lists discovery. How about tags, description, list type, etc.? Also,... I understand your need to test out the API right now, but you've created inequity with the private API access. How can folks like us, who have an app that's closely related to Lists, get access to the Lists API (ie create a level playing field)? Thanks, Nipun @nipj @tweeppacks -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Laying the foundation for API versioning
Ops is working on fixing this. We identified some stale configurations on some hosts (which is why the failures are intermittent). It's currently being worked on and should be resolved soon. Thanks for reporting it. On Wed, Oct 21, 2009 at 10:00 AM, Sal Conigliaro sco...@gmail.com wrote: Hi Marcel- I'm still seeing the cert hostname mismatch. https://api.twitter.com/1/users/show/rwzombie.xml The cert hostname returned is still shown as 'twitter.com'. Sal On Oct 18, 4:36 pm, Marcel Molina mar...@twitter.com wrote: The change has been made but it probably hasn't been pushed out yet to the full cluster. I'll follow up with ops on Monday. Thanks. On Sun, Oct 18, 2009 at 1:10 PM, Dave Briccetti da...@davebsoft.com wrote: Thanks, but still failing today. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Private lists showing up on memberships page
That looks like a bug. Thanks for bringing it to our attention. On Sun, Oct 18, 2009 at 1:49 PM, Damon C d.lifehac...@gmail.com wrote: I've seen a couple instances now (@beaker and @mediaphyter) where a private list shows up on the list of a user's memberships. It doesn't seem like the existence of these private lists should be showing up in the memberships list, nor can I reproduce the issue on my own account. As an example, here's a brief snippet from http://twitter.com/Beaker/lists/memberships.xml (sidenote that the member_count shows up as 5 on the HTML version of the memberships page). list id19351/id nameSecurity/name full_name@twowheelgeek/security/full_name slugsecurity/slug subscriber_count0/subscriber_count member_count0/member_count uri/twowheelgeek/security/uri modeprivate/mode dpc -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Laying the foundation for API versioning
The change has been made but it probably hasn't been pushed out yet to the full cluster. I'll follow up with ops on Monday. Thanks. On Sun, Oct 18, 2009 at 1:10 PM, Dave Briccetti da...@davebsoft.com wrote: Thanks, but still failing today. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Draft of List API documentation
want to remove as a member from the list. (required) Usage notes: The :list_id portion of the request path should be the slug of the list you want to add a member to. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -X DELETE -d id=123456789 http://twitter.com/noradio/tall-people/members.xml GET '/:user/:list_slug/members/:id.:format' Check if a user is a member of the specified list. Usage notes: The :id is the id of the user you're inquiring about. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD http://twitter.com/noradio/tall-people/members/123456789.xml === List subscribers === POST '/:user/:list_slug/subscribers.:format' Subscribe the authenticated user to the specified list. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -X POST http://twitter.com/noradio/tall-people/subscribers.xml GET '/:user/:list_slug/subscribers.:format' List the users subscribed to the specified list. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD http://twitter.com/noradio/tall-people/subscribers.xml DELETE '/:user/:list_slug/subscribers.:format' Unsubscribe the authenticated user from the specified list. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -X DELETE http://twitter.com/noradio/tall-people/subscribers.xml GET '/:user/:list_slug/subscribers/:id.:format' Check if a user subscribes to the specified list. Usage notes: The :id is the id of the user you're inquiring about. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD http://twitter.com/noradio/tall-people/subscribers/123456789.xml More to come soon. Stay tuned! -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Laying the foundation for API versioning
We've taken the first steps toward introducing versioning into the Twitter REST API. With a versioned API we can make ambitious improvements *today*, not tomorrow, without worrying about breaking backwards compatibility. This will lead to both a better and more reliable API. Available right now, the API's new home is at http://api.twitter.com. Currently only one version is supported: version 1 :-) Version 1 should be in all ways functionally equivalent to the API you're using at the main twitter.com url (if you find what seems like an incompatibility please submit what you've found on our issue tracker: http://code.google.com/p/twitter-api/issues/list). To make a request with the new versioned API, you just need to prefix every path with the desired version. For now that's just 1. So for example, what was http://twitter.com/users/show/noradio.xml becomes http://api.twitter.com/1/users/show/noradio.xml For now we're keeping it simple. No subversions, no implicit version defaults, no fancy-pants etc. We're leaving our approach open to these types of additions, but we aren't going to support them until we feel a compelling need to. We haven't yet determined how many versions will be supported at once or how long a version will continue to be supported once it's deprecated. We'll be figuring out answers to these questions once we spend some time supporting multiple versions and seeing how new APIs emerge and iterate. We suspect though that we'll support deprecated versions for at least 6 months. We also don't have a hard date for when API requests to http://twitter.com will no longer be serviced. We aren't planning on pulling the rug out from anyone though. Please update your applications to the new http://api.twitter.com/1 at your soonest convenience. The non API urls likely won't be supported forever. Though having a versioned API should greatly decrease the likelihood that a change in the API breaks your application, one of the notable exceptions is bug fixes. When bugs are discovered they will be fixed and backported immediately to all supported versions of the API. We're kicking the tires on http://api.twitter.com/1 but we hope to have http://api.twitter.com/2 close around the corner. The time has come for us to start knocking off some of the stuff on V2 Roadmap list http://apiwiki.twitter.com/V2-Roadmap. For a while that page has been the dumping ground for all our lofty dreams. Version 2 probably won't be so ambitious that it resolves everything on that list. We want, after all, to get good at managing a multi-version environment before we get all crazy with the nitrous injections and chrome detailing. But we're putting the framework in place that will allow us to more quickly fix the stuff you've struggling with, take chances without putting your work in jeopardy, and all other things that are good. Cheers. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Laying the foundation for API versioning
The OAuth endpoints aren't strictly speaking part of the REST API. http://api.twitter.com/oauth/authorize and family works at the api subdomain, but those paths aren't versioned (though maybe they should be...). As for search...one step at a time ;-) But thanks for noticing. On Fri, Oct 16, 2009 at 12:46 AM, Rich rhyl...@gmail.com wrote: Great news guys, I noticed that the search and oauth API's aren't in the version one API stream though. Is this intentional? -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Laying the foundation for API versioning
I've alerted our ops team. Thanks for the heads up. On Fri, Oct 16, 2009 at 12:56 AM, Rich rhyl...@gmail.com wrote: I did notice though that api.twitter.com doesn't have a valid SSL certificate so any clients using the API over SSL will error out too. On Oct 16, 8:49 am, Marcel Molina mar...@twitter.com wrote: The OAuth endpoints aren't strictly speaking part of the REST API. http://api.twitter.com/oauth/authorizeand family works at the api subdomain, but those paths aren't versioned (though maybe they should be...). As for search...one step at a time ;-) But thanks for noticing. On Fri, Oct 16, 2009 at 12:46 AM, Rich rhyl...@gmail.com wrote: Great news guys, I noticed that the search and oauth API's aren't in the version one API stream though. Is this intentional? -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Draft of List API documentation
Depending on how our performance tests, bug fixes and all the other myriad things go we could be public with the feature as early as a week or two from now. We shall see... On Fri, Oct 16, 2009 at 1:06 AM, Rich rhyl...@gmail.com wrote: This is fantastic, I hope to start working on it soon. Do you guys have and idea of possible timespans, only because it takes us two weeks to get things past Apple's appoval process! On Oct 16, 8:04 am, Marcel Molina mar...@twitter.com wrote: Hey folks. As some of you have likely read we're starting to do some private beta testing of our new lists feature. We're not quite ready to open it up to everyone but we've made some headway on the API and wanted to share some details of what we've got so far. There are a handful of things on our todo lists so don't consider this signed and sealed just yet. You may notice this API is a bit of a departure from the rest of the API. It's a bit more, errr, REST than the rest. First off, here's the current payload for a list: ?xml version=1.0 encoding=UTF-8? list id1416/id nametall people/name full_name@noradio/tall-people/full_name slugtall-people/slug subscriber_count0/subscriber_count member_count3/member_count uri/noradio/tall-people/uri modepublic/mode user id3191321/id nameMarcel Molina/name screen_namenoradio/screen_name locationSan Francisco, CA/location descriptionEngineer at Twitter on the @twitterapi team, obsessed with rock climbing amp; running. In a past life I was a member of the Rails Core team./description profile_image_urlhttp://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_no.../profile_image_url urlhttp://project.ioni.st/url protectedfalse/protected followers_count40059/followers_count profile_background_color9AE4E8/profile_background_color profile_text_color33/profile_text_color profile_link_color0084B4/profile_link_color profile_sidebar_fill_colorDDFFCC/profile_sidebar_fill_color profile_sidebar_border_colorBDDCAD/profile_sidebar_border_color friends_count354/friends_count created_atMon Apr 02 07:47:28 + 2007/created_at favourites_count131/favourites_count utc_offset-28800/utc_offset time_zonePacific Time (US amp; Canada)/time_zone profile_background_image_urlhttp://a1.twimg.com/profile_background_images/18156348/jessica_tiled/profile_background_image_url profile_background_tiletrue/profile_background_tile statuses_count3472/statuses_count notificationsfalse/notifications geo_enabledtrue/geo_enabled verifiedfalse/verified followingfalse/following /user /list === Lists === POST '/:user/lists.:format' Creates a new list for the authenticated user. Parameters: * name: the name of the list. (required) * mode: whether your list is public of private. Values can be 'public' or 'private'. Public by default if not specified. (optional) Usage notes: :user in the url should be the screen name of the user making the request to create the list Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -d name=tall peoplemode=privatehttp://twitter.com/noradio/lists.xml POST/PUT '/:user/lists/:list_slug.:format' Updates the specified list. Takes the same parameters as the create resource at POST '/:user/lists.:format' (:name and :mode). Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -d name=giantsmode=publichttp://twitter.com/noradio/lists/tall-people.xml GET '/:user/lists.:format' Lists your lists. Supported format: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists.xml GET '/:user/lists/memberships.:format' List the lists the specified user has been added to. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/memberships.xml DELETE '/:user/lists/:list_slug.:format' Delete the specified list owned by the authenticated user. Parameters: * list_slug: the slug of the list you want to delete. (required) Supported formats: xml, json e.g. curl -u USERNAME:PASSWORD -X DELETEhttp://twitter.com/noradio/lists/tall-people.xml GET '/:users/lists/:list_slug/statuses.:format' Show tweet timeline for members of the specified list. Parameters: * list_slug: the slug of the list you want the member tweet timeline of. (required) * next/previous_cursor: used to page through results (optional) Supported formats: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/tall-people/statuses.xml GET '/:users/lists/:list_slug.:format' Show a specific list you can use the new resource. Supported formats: xml, json e.g. curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/lists/tall-people.xml === List members === POST '/:user/:list_slug/members.:format' Add a member to a list. Parameters: * id: the id of the user you want to add as a member
[twitter-dev] Re: Laying the foundation for API versioning
Thanks for the report. Looking into it. On Fri, Oct 16, 2009 at 12:55 PM, Dave Briccetti da...@davebsoft.com wrote: DELETE http://twitter.com/friendships/destroy/USER.xml works, but DELETE http://api.twitter.com/1/friendships/destroy/USER.xml fails with You don't have permission to access /1/friendships/destroy/USER.xmlon this server. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Laying the foundation for API versioning
This was an oversight in a server configuration. We've made the change and should be pushing it out at some point today. Thanks again. On Fri, Oct 16, 2009 at 12:55 PM, Dave Briccetti da...@davebsoft.com wrote: DELETE http://twitter.com/friendships/destroy/USER.xml works, but DELETE http://api.twitter.com/1/friendships/destroy/USER.xml fails with You don't have permission to access /1/friendships/destroy/USER.xmlon this server. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Seeing retweeted_details for user_timeline payload
Having retweets in the user_timeline isn't intentional. I'll be ensuring they don't appear there in the next few days. The only place they should be appearing (once publicly available) is the home_timeline. On Wed, Oct 14, 2009 at 7:45 PM, Martin martin.duf...@gmail.com wrote: I'm retrieving the timeline for a specific user: curl http://www.twitter.com/statuses/user_timeline/ev.xml Within that timeline, I see retweeted_status fragment. Is this normal behavior ? Thanks - Martin -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Seeing retweeted_details for user_timeline payload
Updating the retweet doc payloads is on my todo list. It's unfortunately currently a tedious and onerous task. I've been using my cycles on other things. But it's on the list to do. On Thu, Oct 15, 2009 at 1:53 PM, Josh Roesslein jroessl...@gmail.com wrote: The API doc on the wiki is not correct. There was an email sent out earlier about the new payload format. Could someone update the wiki for the new payload? Josh On Thu, Oct 15, 2009 at 3:48 PM, Rich rhyl...@gmail.com wrote: Hmm except this API payload doesn't match that for the home_timeline Hometimeline shows retweet_status with a sub tag of retweeting_user, but yet @ev's user timeline shows a tag of retweet_status with a subtag of user. I want to support it but not with the inconsistency in the API On Oct 15, 5:18 pm, Martin martin.duf...@gmail.com wrote: I have no problem with this new API call. But why is it also included in the user_timeline payload ? Is this inclusion official on the Twitter side... Martin On Oct 15, 9:46 am, ryan alford ryanalford...@gmail.com wrote: http://apiwiki.twitter.com/Twitter-REST-API-Method:-statuses-home_tim... http://apiwiki.twitter.com/Twitter-REST-API-Method:-statuses-home_tim...That will be the new Friends Timeline. It will include retweets, while the current Friends Timeline will not. The current Friends Timeline will also be going away at some point in the future. Ryan On Thu, Oct 15, 2009 at 8:53 AM, Martin martin.duf...@gmail.com wrote: Thanks for the clarification. That explains the inconsistent behavior we are seeing when trying to load specific user timelines. Do we have an updated api wiki that defines the semantics of the retweeted_status fragment ? Martin www.wherecloud.com On Oct 14, 10:59 pm, Josh Roesslein jroessl...@gmail.com wrote: I think its been enabled for a select few for testing. I don't think its gone public yet. On Wed, Oct 14, 2009 at 9:56 PM, ryan alford ryanalford...@gmail.com wrote: Maybe the new retweet functionality has been turned on? Ryan On Wed, Oct 14, 2009 at 10:45 PM, Martin martin.duf...@gmail.com wrote: I'm retrieving the timeline for a specific user: curlhttp://www.twitter.com/statuses/user_timeline/ev.xml Within that timeline, I see retweeted_status fragment. Is this normal behavior ? Thanks - Martin -- Josh -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Lists API
We are rolling it out to a small set of users incrementally so that we can load test and find bugs. We've been working on the API documentation and will be rolling it out gradually. On Thu, Oct 15, 2009 at 4:10 PM, Eric Woodward e...@nambu.com wrote: So, what is the plan for releasing the Lists API, if there is one? It is well known that selected people have access to them while the rest of us do not, which is creating a problem with users. Is there a plan to release these APIs to everyone soon? Please respond. I am only asking. --ejw Eric Woodward Email: e...@nambu.com -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] New spam reporting API now available
On the heels of adding a Report as spam button to twitter.com (http://blog.twitter.com/2009/10/help-us-nail-spammers.html), you can now also simultaneously block and report a user as a spammer via the API. The documentation for the report_spam resource can be found here: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-report_spam As the original announcement mentions, it's important to realize no automated action will be taken as a result of a spam report being created. So don't expect an account to be suspended immediately (or at all). Also you can only create one spam report for a given user, so subsequent requests will have no result. Thanks. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Multiple language support for your Twitter application
Over on the main Twitter blog we've just announced that we'll be translating the site into French, Italian, Spanish and German soon, with more languages to come later (http://bit.ly/LIa4C). We figured a lot of folks building apps on the Twitter Platform might be interested in providing their applications in various languages too but haven't had the time or resources to take on building up full translations. So we are planning to provide our translation files to the developer community. We hope they're useful as at least a starting point for your own. We're just getting started. We'll follow up with more details about where you'll be able to get these translations soon. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Updates to the retweet API payload
We've updated the retweet payload to look a lot more like a regular tweet's payload. We find this change makes the retweet API conceptually simpler, easier and more convenient to work with and better overall. I've linked to examples of the new payload below, and will be updating documentation shortly, but first I'd like to share some background on what we've learned working on the retweet API over the past few weeks. One of the big objectives of the retweet feature is discovering new users to follow. We wanted the original status and its author highlighted front and center so they get due credit for the tweet someone you follow found worthy of retweeting. To that end the API was designed to emphasize the original tweet by having it be the top level object. Embedded within it we provided details about who retweeted it and when. Though this makes a statement to how we'd like the feature to be thought about, logistically it doesn't degrade gracefully for clients who don't implement any retweet logic in their code. Tweets appear in timelines from people who you do not follow and unless clients differentiate those tweets visually letting you know that someone you follow has shared this tweet, confusion ensues. To mitigate this, we opted to not include retweets into the existing friends timeline. Instead we created a new parallel home timeline that would be just like the friends timeline but included retweets. That way developers could opt in to the retweet feature at their leisure. Even with this opt in policy, though, there is still a critical responsibility imposed on developers to clearly communicate to their users that a given tweet in their timeline is a retweet and who the retweet is from. The likelihood that confusion would result turned out to be too high. Additionally, with the original status as the top level object in the payload, that means consumers of the API would receive what appears to be the same tweet multiple times. In a lot of cases that's fine, in others it's problematic. After experimenting with this approach we've decided that it's a better bet to craft a payload that will degrade far more gracefully. So we've redesigned the retweet payload. Rather than having the original tweet as the top level status with embedded details about who retweeted it, the retweet is the top level object and within it we include the original tweet and its author. You'll have full access to the entire retweeted status and user as well as the original tweet and its user. So you don't have to make any additional API calls and should have everything you need to display a retweet distinctively with attribute to both the original author and the retweeter. In other words, these retweeted statuses look a whole lot like regular statuses. This new design was our instinct to begin with and we probably should have gone with it. We think it's better and hope you do too. All the same documented resources will exist. Only the payloads change. The following timeline should contain examples of the updated retweet payload. You can use this to test consuming retweets. curl http://twitter.com/statuses/user_timeline/testiverse.xml curl http://twitter.com/statuses/user_timeline/testiverse.json In the event that new tweets go into the above timeline that push the retweets out, you can access a few directly at the following urls: curl http://twitter.com/statuses/show/4452134416.xml curl http://twitter.com/statuses/show/4452466408.xml curl http://twitter.com/statuses/show/4349744308.xml The above payloads don't contain a retweet_count element yet and they probably will. Other than that we don't suspect any more major changes as we approach a full public launch. As always, though, we're open and solicitous of everyone's feedback. Thanks. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] New Twitter feature API coming soon: Lists
Over on the main Twitter blog @nk has written about a new Lists feature we're getting ready to launch: http://blog.twitter.com/2009/09/soon-to-launch-lists.html. We just wanted to let API developers know that we'll be shipping an API for it on day one. You'll be able to do things like create lists, add and remove users from lists, find out who has been added to a list and read the tweet timeline for a given list. Stay tuned for documentations on the full Lists API soon. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Deleting a Retweeted Tweet
If the original retweet is deleted its retweets will also disappear. On Sun, Sep 20, 2009 at 3:56 PM, Dewald Pretorius dpr...@gmail.com wrote: With the new retweeting, what happens with retweets if the original tweet is deleted, or the author's account is closed or suspended? Do all the retweets of that tweet also just disappear with it? Dewald -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
The Retweet API launch is close at hand. You might have already seen some retweets appearing in the new statuses/home_timeline from people who've been testing them out. We've gotten lots of great questions and feedback about the retweet API. Thanks to everyone who has rolled up their sleeves and gotten involved. It's been a big help. One of the main confusions and criticisms about the retweet API was around what happens when a given tweet is retweeted multiple times. The explanation was that developers need to do their own retweet collapsing. If N people retweet a given tweet, you'd get N instances of that same tweet in the appropriate retweet timeline and the home timeline. You would then have to do your own internal book keeping about whether that tweet had already come in. If it hadn't you'd display it for the first time. If it had you'd update the already displayed tweet. Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the first retweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Here is the documentation for the new resource, statuses/retweets: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets Sincere apologies if you've already written collapsing logic for retweets. Beta releases are beta releases and I think the retweet API is a lot better without the onerous collapsing requirement. To give you some ideas of how you can use the API to display retweets, here is a recent mock up of one of the potential UIs for the retweets timeline on twitter.com: http://a1.twimg.com/example-retweet-ui-18-sep-09.png If you've got questions, find bugs, or have any kind of feedback, get in touch via the dev mailing list, send an @reply to @twitterapi or jump into the #twitterapi IRC channel on irc.freenode.net. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Draft: Twitter Rules for API Use
To accompany our updated Terms of Service (http://bit.ly/2ZXsyW) we've posted a draft of the Twitter API rules at http://twitter.com/apirules. As the subject states, these rules are a work in progress and feedback is welcome. Please read the TOS announcement at http://bit.ly/2ZXsyW for some background. We encourage you to use the contact us link at http://twitter.com/apirules with any feedback you may have. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: [ANN] statuses/home_timeline resource now available (though it doesn't include retweets yet)
The friends_timeline will likely be around for an amount of time on the scale of months, rather than weeks. On Thu, Sep 3, 2009 at 3:03 AM, Richrhyl...@gmail.com wrote: Any idea how long the friends_timeline will be available for, obviously there might be some considerable development time assocated with switching (and in the case of iPhone applications getting Apple to review the whole process too!) On Sep 3, 1:19 am, Marcel Molina mar...@twitter.com wrote: The current friends_timeline and home_timeline both include mentions already. The friends_timeline will continue to not include retweets since the payload for a retweeted status is slightly different. At some future time, though, the friends_timeline will be removed in favor of the home_timeline, which will include retweets. Having both parallel timelines, with one that does not include retweets is just a stop gap measure to ease the upgrade path. On Wed, Sep 2, 2009 at 4:56 PM, TjLluo...@gmail.com wrote: from the API page Twitter REST API Method: statuses/home_timeline [COMING SOON] Returns the 20 most recent statuses, including retweets, posted by the authenticating user and that user's friends. This is the equivalent of /timeline/home on the Web. Usage note: This home_timeline is identical to statuses/friends_timeline except it also contains retweets, which statuses/friends_timeline does not (for backwards compatibility reasons). In a future version of the API, statuses/friends_timeline will go away and be replaced by home_timeline. Does this mean that in a future version of the API there won't be any way to get a friends timeline without retweets? Because the ability to ignore retweets ought to be a Day 1 feature, IMO. I would put a much higher value on a unified feed which includes *mentions* and friends than *retweets* and friends FWIW TjL -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
