[twitter-dev] Need beta testers

[Dale Folla MeDia]

Hi Everyone,

A new Twitter App is born and launched as
http://www.Fol.la.
Thanks for everyone's input during development.  If there is
anyone interested in helping us with beta testing, please send me an email
at d...@fol.la.  I will only need your Twitter Username: We will enable a
premium service for you to use in exchange for some honest feedback.  We
have one premium service delivered now, and have two more coming out in
November.

Thanks in advance, for your help!

-- 
Dale
Fol.la MeDia, LLC

[twitter-dev] Re: Serial or Parallel? Does it make a difference for the API?

[Dave Briccetti]

Alex Payne told me several months ago at a Bay Area Scala Enthusiasts
meeting that parallel operations are fine.

[twitter-dev] Serial or Parallel? Does it make a difference for the API?

[Ryan Rosario]

I am working on a fairly large research project so I am in the process
of trying to retrieve the most recent 200 tweets for 400,000 users. It
didn't seem like a problem because individual queries took about 1
second to return. Among 5 machines then, this should take about 22.2
hours assuming each request takes 1 second.

After 24 hours, I have retrieved only 25,000 users. Of course, I
realize there is variance in my 1 user/second estimate, but this seems
quite slow, retrieving between 10 and 80 users per minute, I was
expecting to be blocked by rate limiting each hour, but I am nowhere
even close to hitting the 20,000/hr whitelist limit.

Might it be better to parallelize this process using map/reduce to
make several requests simultaneously? Or does the Twitter API HTTP
block the other requests while waiting for the first to complete?

[twitter-dev] Re: Laying the foundation for API versioning

[Marcel Molina]

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  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

[Marcel Molina]

Thanks for the report. Looking into it.

On Fri, Oct 16, 2009 at 12:55 PM, Dave Briccetti  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: Duplicate Tweets

[Andy Freeman]

One thing to do is include the date/time that no chains are required.

In general, status messages should be timestamped because it's almost
always important to know when they were generated.  Yes, tweets are
timestamped, but that's the tweet's timestamp, not the date that the
status was actually generated by the service.  (Yes, the two will be
reasonably close when things are going well, but )

On Oct 15, 11:01 pm, John Kalucki  wrote:
> I don't know about paygrade, but more than a few Twitter employees
> follow i80chains during the season. We hear you. I just don't know
> what to suggest be done about the situation.
>
> On Oct 15, 11:09 am, Toxic  wrote:
>
>
>
> > On Oct 15, 7:50 am, Ryan Sarver  wrote:
>
> > > 1. Duplicate tweets HAS always been considered a violation.
>
> > Sure, it's always been a reason to kick someone off, but by attempting
> > to automatically police it, you've managed to take out a couple of
> > quite legitimate services, some of which were using twitter in new and
> > interesting ways.
>
> > But for those collecting examples of collateral damage, I've got
> > another one for you.  Perhaps someone "above the approptiate pay
> > grade" at Twitter is a skier/rider?  Because this change in behavior
> > (even if it's not a change in policy) is going to eliminate two
> > resources that Bay Area skiers tend to use.  Neither seems like
> > something that Twitter wants to shut off, but neither can continue to
> > operate with the current de-duplication filters:
>
> > @i80chains.  That rebroadcasts Caltrans's announcements for Interstate
> > 80 in the Sierra Nevadas. During the winter, it lets people know when
> > chains are required to drive over Donner Pass.  When chain control is
> > turned off, it tweets "OPEN: NO RESTRICTIONS" (or something to that
> > effect).  That "all clear" tweet is getting caught by the filters,
> > which leaves out-of-date information on the stream/feed.  It is as
> > important to receive a tweet that says "you don't need chains" as it
> > is to receive one that says "you'll need them from Kingvale to
> > Truckee", but as of right now, only one is allowed to get through.
>
> > @tahoe_weather.  Rebroadcasts National Weather Service warnings/
> > watches and announcements relevant to people in Tahoe.  It also has a
> > "No active advisory" tweet that it sends out when there are no longer
> > any active weather statements.  Again, these "all clear" tweets are
> > getting filtered, which rather drastically reduces the usefulness of
> > the bot.
>
> > > 2. In the Spam section of that policy we also clearly state that the rules
> > > will be changing as we adapt to new tactics
>
> > I understand that it's impossible to really define spam and/or abuse,
> > and that anything that's ultimately an announcement-bot is going to be
> > walking a fine line.  But those two bots above seem like they're not
> > remotely abusive, do seem like they're useful, and they're getting
> > swept up among the spammers.- Hide quoted text -
>
> - Show quoted text -

[twitter-dev] Re: Laying the foundation for API versioning

[Dave Briccetti]

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.

[twitter-dev] Re: http return 0

[Scott Haneda]

Correct, error 0 means no data was returned, and that the timeout in  
curl was hit, which I have set to 10 seconds.  I am seeing about 5 of  
these per Admin block 24 hours, out of around 300 calls per 24 hours.


I see a lot more of them when I see more of the 502 errors, which  
seems to tell me that when twitter is over capacity there is a  
tendency for them to completely close down the port for communication  
all together.


What is annoying about this, is that twitter.com is fine during all  
this, their public timeline works 100%, yet my API driven calls to the  
public timeline are getting error 0 and 502 many times per day.

--
Scott * If you contact me off list replace talklists@ with scott@ *

On Oct 15, 2009, at 1:45 PM, JDG wrote:

i think http 0 in curl just means the connection failed. should  
probably just retry.

[twitter-dev] Re: The little twitter button

[Dawg]

Thanks Jonathan, that was exactly what I was looking for. I keep
looking for something using  "share" or "website sharing" who the heck
knew it was tweetmeme. I have found Twitter a rather difficult site to
navigate and find things.

What I did and it worked (but the twitter script is better) was I
copied a link from another site and dissected it.

Coming up with this. The quotation marks are escaped because it is
inserted from a php script after a DB retrieval.

http://twitter.com/home?status=$share_title $url_link\">

The $ share_title is a string trimmed to the specific length (80)
otherwise it does not work. the $url_link is the link to the article.


Thanks for the help.
Dave

[twitter-dev] Re: Download Avira AntiVir Premium v9.0.0.446 with 2011 valid

[John Meyer]

Looks like Alex's getting attacked from a swiss server.


JDG wrote:

dammit al3x!

On Fri, Oct 16, 2009 at 06:39, Kola zone > wrote:


Download Avira AntiVir Premium v9.0.0.446 with 2011 valid
 
http://bit.ly/2dWFN5
 
http://bit.ly/2dWFN5
 
Download Avira AntiVir Premium v9.0.0.446 with 2011 valid





--
Internets. Serious business.

[twitter-dev] Re: Download Avira AntiVir Premium v9.0.0.446 with 2011 valid

[JDG]

dammit al3x!

On Fri, Oct 16, 2009 at 06:39, Kola zone  wrote:

>  Download Avira AntiVir Premium v9.0.0.446 with 2011 valid
> **
> http://bit.ly/2dWFN5
> http://bit.ly/2dWFN5
>
>  Download Avira AntiVir Premium v9.0.0.446 with 2011 valid
>



-- 
Internets. Serious business.

[twitter-dev] Re: Non-standard HTTP Errors? httplib.BadLineStatus

[Oren Rose]

Although I'm not using these libraries, sometimes I get broken
responses from Twitter.

I vote for Josh - in these cases just re-try. Usually it solves the
problem.

= Oren

On Oct 15, 7:48 pm, Josh Roesslein  wrote:
> Hi Ryan,
>
> Hmm that is an odd error. I have not really experienced this in my
> Tweepy library
> during development. I don't use urllib2, but instead httplib directly.
> If this just happens
> once in a while maybe just catch that error and just retry the request.
>
> Josh
>
>
>
>
>
> On Thu, Oct 15, 2009 at 12:33 PM, Ryan Rosario  wrote:
>
> > I use Python for most of my development with the Twitter API, and I
> > have been using urllib2 to extract content.
>
> > After running my scripts for some period of time (sometimes 5 mins,
> > sometimes several hours) I get an httplib.BadLineStatus exception. All
> > I could find on this error is that it means the server sent an HTTP
> > error that is non-standard (?). The exception was passed up to the
> > httplib from urllib2.
>
> > This also happened with DeWitt's Python package (which uses urllib2).
>
> > Without knowing what content is being returned (if any), I am having a
> > difficult time nailing down what is causing this exception. Has
> > anybody else experienced this problem? Is there any way to prevent it?
> > (right now I am just retrying the request)
>
> --
> Josh

[twitter-dev] Re: Draft of List API documentation

[Bill Kocik]

Hi Marcel -

First, thanks for the preview, this is very helpful.

Second, a question: When retrieving an existing timeline such as /
statuses/friends_timeline, or a list of friends from /statuses/
friends, will there be any indication in the output as to which list
(s) the authenticated user is subscribed to that each friend is on?
The use case I'm thinking of is list management from the timeline
interface, where an end user might be able to see right there which
list(s) a friend is on, or (more interestingly) which friends aren't
on any of their lists yet.

Thanks...

[twitter-dev] Re: The little twitter button

[Jonathan Markwell]

Hi  Dave,

It sounds like you might be talking about Tweetmeme's retweet button:

http://help.tweetmeme.com/2009/04/06/tweetmeme-button/

Hope this helps,

Jon.

On Thu, Oct 15, 2009 at 7:13 PM, Dawg  wrote:
>
> Thanks guys but none of those do it.
>
> What I found on Face Book (and expected to find on Twitter) was a
> small script (below) which is in the php page that renders the
> article.
>
>  http://static.ak.connect.facebook.com/js/api_lib/v0.4/
> FeatureLoader.js.php/en_US" type="text/javascript">

[twitter-dev] Re: Draft of List API documentation

[Kevin Makice]

This is great.

Will there be some mechanism to keep track on new and changed lists
coming from the Twitter community, like a public timeline for list
creation? Or is the only way to become aware of lists through the API
to start checking users for their list creation/inclusion?

[twitter-dev] Re: What is 140 characters?

[Cameron Kaiser]

Just to follow up on Matt's note,

> I'm sorry this never got updated. Some changes have been made and
> are waiting to go out now. When I switched from working on the
> Platform (formerly API) team to my focus on international I took over
> this issue.
> Once this current fix is deployed (probably in a week or so since
> I'm traveling at the moment) the definition of a character will be
> consistent throughout our API. The new change will always compute
> length based on the Unicode NFC [1] version of the string. Using the
> NFC form makes the 140 character limit based on the length as
> displayed rather than some under-the-cover byte arithmetic.

Has this change occurred yet? I have a fix in TTYtter ready to go to enable
140 *character* posts instead of bytes, but I don't want to deploy it until
I know the path is clear.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- armadillo, n. the act of providing weapons to a Spanish pickle. 

[twitter-dev] Re: Draft of List API documentation

[Cameron Kaiser]

> 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.

Thanks for the list API description. I like the general appearance.
One request:

> 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 DELETE
> http://twitter.com/noradio/lists/tall-people.xml

This is slightly pedantic but currently the entirety of the API can be
accessed with GET and POST methods, even tweet and DM deletion (DELETE is
supported facultatively but not obligatorily), which happily allows old
clients like Lynx to still be used for API access. Could a delete stub
method via POST be added to the API to maintain consistency?

It would make sense to mandate a full and proper REST implementation using
the full breadth of HTTP methods in API v2, but I think for consistency
there should be a POST-accessible delete method at least in this
implementation unless Lists API is going to be an API v2 feature only.

Otherwise, I am very much looking forward to supporting lists in TTYtter
(and, when you get around to the next wave, trying it out on the Web).

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- When in doubt, use brute force. -- Ken Thompson 

[twitter-dev] Re: Seeing retweeted_details for user_timeline payload

[Martin]

Thanks for the clarification Marcel.

And as an FYI, clients using old version of MGTwitterEngine, will not
properly parsed status payloads with that  fragment
and will crash.
This is mostly affecting iPhone clients that are using these old
versions.
And unfortunately the current version of our app is also affected.

L8er - Martin
www.wherecloud.com

On Oct 15, 6:49 pm, Marcel Molina  wrote:
> 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  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
>
> --
> Marcel Molina
> Twitter Platform Teamhttp://twitter.com/noradio

[twitter-dev] Re: Laying the foundation for API versioning

[Thomas Woolway]

Hi John,
I'm still getting SSL issues with api.twitter.com - it seems like some
attempts get the wildcard certificate, some get the old one. This is using
Chrome and AIR.

Let me know if you need any more information,

Tom

On Fri, Oct 16, 2009 at 11:14 AM, Rich  wrote:

>
> Hi John, I replied directly to you, but didn't realise it was also
> sent to the dev list.
>
> Basically it seems to have gone now as I see the cert is a wildcard
> one, this morning both the iPhone and Firefox were complaining that
> the cert was for twitter.com and not api.twitter.com
>
> Richard
>
> On Oct 16, 11:04 am, John Adams  wrote:
> > Could you let us know what errors you are seeing via SSL on
> > api.twitter.com? I'd like to investigate.
> >
> > I do not see any SSL errors under Firefox and/or Safari on 10.5 nor
> > 10.6.
> >
> > -j
> >
> > On Oct 16, 2009, at 1:00 AM, Marcel Molina wrote:
> >
> >
> >
> >
> >
> > > I've alerted our ops team. Thanks for the heads up.
> >
> > > On Fri, Oct 16, 2009 at 12:56 AM, Rich  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  wrote:
> > >>> The OAuth endpoints aren't strictly speaking part of the REST API.
> >
> > >>>http://api.twitter.com/oauth/authorizeandfamily 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  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
> >
> > --
> > John Adams
> > Twitter Operations
> > j...@twitter.com
> > Follow me: @netik

[twitter-dev] whitelisting rejection with blank reason

[Pavel Serdyukov]

Hi!

I sent a request for whitelisting (for my account and a list of IPs)
about five days ago and it has been rejected without a reason
specified. There is blank line after " Here's why:".

I used the username: "socialmining".

May I ask for someone's advice here, so how should I proceed further?

Best regards, Pavel Serdyukov, Delft University of Technology

[twitter-dev] Re: Duplicate Tweets

[Dean Collins]

Simple solution, have the robot tweet the time and date along with the 
'advisory message'.

This would be enough to get around twitters filters 

 

 

Cheers,

Dean

 


-Original Message-
From: twitter-development-talk@googlegroups.com 
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Sean Lindsay
Sent: Friday, October 16, 2009 3:40 AM
To: Twitter Development Talk
Subject: [twitter-dev] Re: Duplicate Tweets


Can I suggest:

A RepeatTweet API. Permit the delivery of marked duplicate tweets on
the Twitter side, with an API to allow external apps/services to
integrate it.

The system could permit (and only permit) RepeatTweets with a
 tag indicating the duplicated tweet, sent through the
API. This would allow Search to filter out duplicates, and other apps
could filter out duplicates that the user has already seen/marked as
read. This would also allow external apps/services to provide the
scheduling. RepeatTweets could be rate-limited (say 5 per 24h per
account) to reduce spam.

This would facilitate most of the usage cases I've read in this thread
-- except emergency services, where duplicated tweets shouldn't be
filtered out because the duplicate text refers to a new/changed
condition. Perhaps a whitelist of such emergency services should be
exempted from the exiting duplicate filters.

Regards,

Sean Lindsay

On Oct 16, 5:01 pm, John Kalucki  wrote:
> I don't know about paygrade, but more than a few Twitter employees
> follow i80chains during the season. We hear you. I just don't know
> what to suggest be done about the situation.

[twitter-dev] Re: Duplicate Tweets

[Sean Lindsay]

Can I suggest:

A RepeatTweet API. Permit the delivery of marked duplicate tweets on
the Twitter side, with an API to allow external apps/services to
integrate it.

The system could permit (and only permit) RepeatTweets with a
 tag indicating the duplicated tweet, sent through the
API. This would allow Search to filter out duplicates, and other apps
could filter out duplicates that the user has already seen/marked as
read. This would also allow external apps/services to provide the
scheduling. RepeatTweets could be rate-limited (say 5 per 24h per
account) to reduce spam.

This would facilitate most of the usage cases I've read in this thread
-- except emergency services, where duplicated tweets shouldn't be
filtered out because the duplicate text refers to a new/changed
condition. Perhaps a whitelist of such emergency services should be
exempted from the exiting duplicate filters.

Regards,

Sean Lindsay

On Oct 16, 5:01 pm, John Kalucki  wrote:
> I don't know about paygrade, but more than a few Twitter employees
> follow i80chains during the season. We hear you. I just don't know
> what to suggest be done about the situation.

[twitter-dev] Re: Laying the foundation for API versioning

[leonspencer]

Marcel,

Is the API description available as a markup file (e.g. XSD)? Or is
there some other way of programmatically scanning the APi that I've
missed.

Thank you,
Leon

On Oct 16, 12:26 am, Marcel Molina  wrote:
> 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 athttp://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 tohttp://twitter.comwill 
> no longer be serviced. We aren't planning on
> pulling the rug out from anyone though. Please update your
> applications to the newhttp://api.twitter.com/1at 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 onhttp://api.twitter.com/1but we hope to
> havehttp://api.twitter.com/2close around the corner. The time has
> come for us to start knocking off some of the stuff on V2 Roadmap 
> listhttp://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 Teamhttp://twitter.com/noradio

[twitter-dev] Re: Laying the foundation for API versioning

[Rich]

Hi John, I replied directly to you, but didn't realise it was also
sent to the dev list.

Basically it seems to have gone now as I see the cert is a wildcard
one, this morning both the iPhone and Firefox were complaining that
the cert was for twitter.com and not api.twitter.com

Richard

On Oct 16, 11:04 am, John Adams  wrote:
> Could you let us know what errors you are seeing via SSL on  
> api.twitter.com? I'd like to investigate.
>
> I do not see any SSL errors under Firefox and/or Safari on 10.5 nor  
> 10.6.
>
> -j
>
> On Oct 16, 2009, at 1:00 AM, Marcel Molina wrote:
>
>
>
>
>
> > I've alerted our ops team. Thanks for the heads up.
>
> > On Fri, Oct 16, 2009 at 12:56 AM, Rich  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  wrote:
> >>> The OAuth endpoints aren't strictly speaking part of the REST API.
>
> >>>http://api.twitter.com/oauth/authorizeandfamily 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  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
>
> --
> John Adams
> Twitter Operations
> j...@twitter.com
> Follow me: @netik

[twitter-dev] Re: Laying the foundation for API versioning

[John Adams]

Could you let us know what errors you are seeing via SSL on  
api.twitter.com? I'd like to investigate.


I do not see any SSL errors under Firefox and/or Safari on 10.5 nor  
10.6.


-j


On Oct 16, 2009, at 1:00 AM, Marcel Molina wrote:



I've alerted our ops team. Thanks for the heads up.

On Fri, Oct 16, 2009 at 12:56 AM, Rich  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  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  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


--
John Adams
Twitter Operations
j...@twitter.com
Follow me: @netik

[twitter-dev] Re: Draft of List API documentation

[Dave Briccetti]

If anyone’s interested, here’s the commit for TalkingPuffin for
preliminary support for displaying lists:

  
http://github.com/dcbriccetti/talking-puffin/commit/ea86bfb523d7aea98df6ebae52893c16f53fa542

A picture of the feature:

  http://www.flickr.com/photos/dcbriccetti/4015781495/

[twitter-dev] Retweets API and Paging

[Mark Hawker]

Having looked at the statuses/retweets method I wondered if you were
going to introduce paging to the returned results? On your new mock-up
there is a "Retweeted By X and Y Others" taster but since there are no
paging parameters you'd have to load all 100 retweets (say) and then
control showing/hiding results externally rather than just loading 10
at a time for example and then paging if the user clicks "More".

The example also has a rogue retweet_count element inside the second
retweet. Wasn't sure whether this should be hanging off the retweets
parent of just not included at all?

[twitter-dev] Re: Draft of List API documentation

[Rich]

Yeah I'm holding off committing to code until we have the formal API
docs and I can see how this works on the live site.

On Oct 16, 10:02 am, Andrew Badera  wrote:
> Any chance of massive UI changes? Unless I'm missing something, the
> List features is totally unmanageable via the GUI for anyone with more
> than a couple dozen followers.
>
> ∞ Andy Badera
> ∞ +1 518-641-1280
> ∞ This email is: [ ] bloggable [x] ask first [ ] private
> ∞ Google me:http://www.google.com/search?q=andrew%20badera
>
> On Fri, Oct 16, 2009 at 3:04 AM, Marcel Molina  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:
>
> > 
> > 
> >  1416
> >  tall people
> >  @noradio/tall-people
> >  tall-people
> >  0
> >  3
> >  /noradio/tall-people
> >  public
> >  
> >    3191321
> >    Marcel Molina
> >    noradio
> >    San Francisco, CA
> >    Engineer at Twitter on the @twitterapi team, obsessed
> > with rock climbing & running. In a past life I was a member of the
> > Rails Core team.
> >    
> > http://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_no...
> >    http://project.ioni.st
> >    false
> >    40059
> >    9AE4E8
> >    33
> >    0084B4
> >    DDFFCC
> >    BDDCAD
> >    354
> >    Mon Apr 02 07:47:28 + 2007
> >    131
> >    -28800
> >    Pacific Time (US & Canada)
> >    
> > http://a1.twimg.com/profile_background_images/18156348/jessica_tiled
> >    true
> >    3472
> >    false
> >    true
> >    false
> >    false
> >  
> > 
>
> > === 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 people&mode=private"
> >http://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=giants&mode=public"
> >http://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 DELETE
> >http://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:PASSWORD
> >http://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 to the list. 
> > (required)
>
> > Usage notes:
> > The :list_slug 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 -d "id=123456789"
> >http://http://twitter.com/noradio/tall-people/members.xml
>
> > GET '/:user/:list_slug/members.:format'
> > Members of the specified list.
>
> > Supported formats:
> > xml, json
>
> > e.g.
> >  curl -u USERNAME:PASSWORDh

[twitter-dev] Re: [twitter-api-announce] Draft of List API documentation

[Andrew Badera]

Any chance of massive UI changes? Unless I'm missing something, the
List features is totally unmanageable via the GUI for anyone with more
than a couple dozen followers.

∞ Andy Badera
∞ +1 518-641-1280
∞ This email is: [ ] bloggable [x] ask first [ ] private
∞ Google me: http://www.google.com/search?q=andrew%20badera



On Fri, Oct 16, 2009 at 3:04 AM, Marcel Molina  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:
>
> 
> 
>  1416
>  tall people
>  @noradio/tall-people
>  tall-people
>  0
>  3
>  /noradio/tall-people
>  public
>  
>    3191321
>    Marcel Molina
>    noradio
>    San Francisco, CA
>    Engineer at Twitter on the @twitterapi team, obsessed
> with rock climbing & running. In a past life I was a member of the
> Rails Core team.
>    
> http://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_normal.jpg
>    http://project.ioni.st
>    false
>    40059
>    9AE4E8
>    33
>    0084B4
>    DDFFCC
>    BDDCAD
>    354
>    Mon Apr 02 07:47:28 + 2007
>    131
>    -28800
>    Pacific Time (US & Canada)
>    
> http://a1.twimg.com/profile_background_images/18156348/jessica_tiled.jpg.jpeg
>    true
>    3472
>    false
>    true
>    false
>    false
>  
> 
>
> === 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 people&mode=private"
> http://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=giants&mode=public"
> http://twitter.com/noradio/lists/tall-people.xml
>
> GET '/:user/lists.:format'
> Lists your lists.
>
> Supported format:
> xml, json
>
> e.g.
>  curl -u USERNAME:PASSWORD http://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:PASSWORD http://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 DELETE
> http://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:PASSWORD
> http://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:PASSWORD http://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 to the list. (required)
>
> Usage notes:
> The :list_slug 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 -d "id=123456789"
> http://http://twitter.com/noradio/tall-people/members.xml
>
> GET '/:user/:list_slug/members.:format'
> Members of the specified list.
>
> Supported formats:
> xml, json
>
> e.g.
>  curl -u USERNAME:PASSWORD http://twitter.com/noradio/tall-people/members.xml
>
> DELETE '/:user/:list_slug/members.:format'
> Remove a member from the specified list.
>
> Parameters:
>  * id: the id of the user you 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:PAS

[twitter-dev] Re: New behaviour for statuses/update API call for 141+ char sized messages and duplicates?

[janole]

According to my tests, messages will not be truncated anymore!

Instead, you will get the most recent status update as a reply.

Is this a bug or feature?

Also, it seems as if the API now checks for duplicates in your
"backlog" of statuses and not just you most recent tweet.

Previously, only the last tweet was checked:

- Last tweet "test"
- Send new tweet with "status=test" will return the old status (with
the old status_id)

but if you had something like this:

Last tweet "Hello, world."
Second last tweet "test"

Then you were able to create a new tweet with "status=test"!

This is not possible at the moment.

Bug or feature?

I'm getting a lot of complaints from my Twitter client users who
apparently experience both of these new "behaviours" or "bugs" (long
tweets fail, duplicates fail.)

Ole @ mobileways.de
On Twitter: http://twitter.com/janole



On Oct 15, 8:26 pm, Josh Roesslein  wrote:
> If you send a message longer than 140 twitter will truncate it and set
> the truncate value on the status to True.
> For duplicates it will just ignore the status.
>
> Josh
>
> On Thu, Oct 15, 2009 at 1:20 PM, janole  wrote:
>
> > Hi,
>
> > I just figured out that when calling statuses/update with a text
> > longer than 140 chars, the reply of that API call will be 200 OK with
> > the last status of the user.
>
> > Wouldn't it be better to return some sort of error message?
>
> > The same seems to be happening when sending a duplicate tweet.
>
> > Ole
>
> > --
> > Jan Ole Suhr
> > s...@mobileways.de
> > On Twitter:http://twitter.com/janole

[twitter-dev] Re: Draft of List API documentation

[Dave Briccetti]

Thanks, Marcel. I’ve started playing with this and it is working
nicely so far.

It would be nice to have a list count included in the user object so
one doesn’t have to make a separate call for each user to see if that
user has lists. Or something else that solves the same problem.

[twitter-dev] Re: Draft of List API documentation

[janole]

Any chance to get on the private beta testing for adding the feature
to my Twitter client or is the API coming later?

Ole ;-)

On Oct 16, 10:11 am, Marcel Molina  wrote:
> 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  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  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:
>
> >> 
> >> 
> >>   1416
> >>   tall people
> >>   @noradio/tall-people
> >>   tall-people
> >>   0
> >>   3
> >>   /noradio/tall-people
> >>   public
> >>   
> >>     3191321
> >>     Marcel Molina
> >>     noradio
> >>     San Francisco, CA
> >>     Engineer at Twitter on the @twitterapi team, obsessed
> >> with rock climbing & running. In a past life I was a member of the
> >> Rails Core team.
> >>     
> >> http://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_no...
> >>     http://project.ioni.st
> >>     false
> >>     40059
> >>     9AE4E8
> >>     33
> >>     0084B4
> >>     DDFFCC
> >>     BDDCAD
> >>     354
> >>     Mon Apr 02 07:47:28 + 2007
> >>     131
> >>     -28800
> >>     Pacific Time (US & Canada)
> >>     
> >> http://a1.twimg.com/profile_background_images/18156348/jessica_tiled
> >>     true
> >>     3472
> >>     false
> >>     true
> >>     false
> >>     false
> >>   
> >> 
>
> >> === 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 
> >> people&mode=private"http://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=giants&mode=public"http://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 to the list. 
> >> (required)
>
> >> Usage notes:
> >> The :list_slug 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 U

[twitter-dev] Re: Draft of List API documentation

[Marcel Molina]

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  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  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:
>>
>> 
>> 
>>   1416
>>   tall people
>>   @noradio/tall-people
>>   tall-people
>>   0
>>   3
>>   /noradio/tall-people
>>   public
>>   
>>     3191321
>>     Marcel Molina
>>     noradio
>>     San Francisco, CA
>>     Engineer at Twitter on the @twitterapi team, obsessed
>> with rock climbing & running. In a past life I was a member of the
>> Rails Core team.
>>     
>> http://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_no...
>>     http://project.ioni.st
>>     false
>>     40059
>>     9AE4E8
>>     33
>>     0084B4
>>     DDFFCC
>>     BDDCAD
>>     354
>>     Mon Apr 02 07:47:28 + 2007
>>     131
>>     -28800
>>     Pacific Time (US & Canada)
>>     
>> http://a1.twimg.com/profile_background_images/18156348/jessica_tiled
>>     true
>>     3472
>>     false
>>     true
>>     false
>>     false
>>   
>> 
>>
>> === 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 
>> people&mode=private"http://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=giants&mode=public"http://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 to the list. (required)
>>
>> Usage notes:
>> The :list_slug 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 -d 
>> "id=123456789"http://http://twitter.com/noradio/tall-people/members.xml
>>
>> GET '/:user/:list_slug/members.:format'
>> Members of the specified list.
>>
>> Supported formats:
>> xml, json
>>
>> e.g.
>>  curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/tall-people/members.xml
>>
>> DELETE '/:user/:list_slug/members.:format'
>> Remove a member from the specified list.
>>
>> Parameter

[twitter-dev] Re: Draft of List API documentation

[Rich]

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  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:
>
> 
> 
>   1416
>   tall people
>   @noradio/tall-people
>   tall-people
>   0
>   3
>   /noradio/tall-people
>   public
>   
>     3191321
>     Marcel Molina
>     noradio
>     San Francisco, CA
>     Engineer at Twitter on the @twitterapi team, obsessed
> with rock climbing & running. In a past life I was a member of the
> Rails Core team.
>     
> http://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_no...
>     http://project.ioni.st
>     false
>     40059
>     9AE4E8
>     33
>     0084B4
>     DDFFCC
>     BDDCAD
>     354
>     Mon Apr 02 07:47:28 + 2007
>     131
>     -28800
>     Pacific Time (US & Canada)
>     
> http://a1.twimg.com/profile_background_images/18156348/jessica_tiled
>     true
>     3472
>     false
>     true
>     false
>     false
>   
> 
>
> === 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 
> people&mode=private"http://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=giants&mode=public"http://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 to the list. (required)
>
> Usage notes:
> The :list_slug 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 -d 
> "id=123456789"http://http://twitter.com/noradio/tall-people/members.xml
>
> GET '/:user/:list_slug/members.:format'
> Members of the specified list.
>
> Supported formats:
> xml, json
>
> e.g.
>  curl -u USERNAME:PASSWORDhttp://twitter.com/noradio/tall-people/members.xml
>
> DELETE '/:user/:list_slug/members.:format'
> Remove a member from the specified list.
>
> Parameters:
>  * id: the id of the user you 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.:for

[twitter-dev] Re: Laying the foundation for API versioning

[Marcel Molina]

I've alerted our ops team. Thanks for the heads up.

On Fri, Oct 16, 2009 at 12:56 AM, Rich  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  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  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: Laying the foundation for API versioning

[Rich]

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  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  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

[twitter-dev] Re: Laying the foundation for API versioning

[Marcel Molina]

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  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

[Rich]

I found the oauth one at http://api.twitter.com/oauth/  Is this the
new location rather than http://twitter.com/oauth/?

On Oct 16, 8:46 am, Rich  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?

[twitter-dev] Re: Laying the foundation for API versioning

[Rich]

Great news guys, I noticed that the search and oauth API's aren't in
the version one API stream though.

Is this intentional?

[twitter-dev] Laying the foundation for API versioning

[Marcel Molina]

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] Draft of List API documentation

[Marcel Molina]

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:



  1416
  tall people
  @noradio/tall-people
  tall-people
  0
  3
  /noradio/tall-people
  public
  
3191321
Marcel Molina
noradio
San Francisco, CA
Engineer at Twitter on the @twitterapi team, obsessed
with rock climbing & running. In a past life I was a member of the
Rails Core team.

http://a3.twimg.com/profile_images/53473799/marcel-euro-rails-conf_normal.jpg
http://project.ioni.st
false
40059
9AE4E8
33
0084B4
DDFFCC
BDDCAD
354
Mon Apr 02 07:47:28 + 2007
131
-28800
Pacific Time (US & Canada)

http://a1.twimg.com/profile_background_images/18156348/jessica_tiled.jpg.jpeg
true
3472
false
true
false
false
  


=== 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 people&mode=private"
http://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=giants&mode=public"
http://twitter.com/noradio/lists/tall-people.xml

GET '/:user/lists.:format'
Lists your lists.

Supported format:
xml, json

e.g.
 curl -u USERNAME:PASSWORD http://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:PASSWORD http://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 DELETE
http://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:PASSWORD
http://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:PASSWORD http://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 to the list. (required)

Usage notes:
The :list_slug 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 -d "id=123456789"
http://http://twitter.com/noradio/tall-people/members.xml

GET '/:user/:list_slug/members.:format'
Members of the specified list.

Supported formats:
xml, json

e.g.
 curl -u USERNAME:PASSWORD http://twitter.com/noradio/tall-people/members.xml

DELETE '/:user/:list_slug/members.:format'
Remove a member from the specified list.

Parameters:
 * id: the id of the user you 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 t