I see your point. Scratch that idea.
Dewald
On Dec 18, 12:43 am, Abraham Williams <4bra...@gmail.com> wrote:
> So say Geo is version 3, RT is version 4 and Lists is version 5. All of
> which are still in beta. If something goes wrong with Geo do they revert to
> 2 and disable RTs and Lists?
>
> A
Correct. I presented a hypothetical issue of a hypothetical solution.
Abraham
On Fri, Dec 18, 2009 at 05:07, Rich wrote:
> Except RT, Geo and Lists are all in the version 1 API directory
>
> On Dec 18, 4:43 am, Abraham Williams <4bra...@gmail.com> wrote:
> > So say Geo is version 3, RT is versi
Except RT, Geo and Lists are all in the version 1 API directory
On Dec 18, 4:43 am, Abraham Williams <4bra...@gmail.com> wrote:
> So say Geo is version 3, RT is version 4 and Lists is version 5. All of
> which are still in beta. If something goes wrong with Geo do they revert to
> 2 and disable RT
So say Geo is version 3, RT is version 4 and Lists is version 5. All of
which are still in beta. If something goes wrong with Geo do they revert to
2 and disable RTs and Lists?
Abraham
On Thu, Dec 17, 2009 at 21:03, Dewald Pretorius wrote:
> Josh,
>
> This will not protect us against a case whe
Josh,
This will not protect us against a case where something central to
Twitter functioning malfunctions, but it will protect us against new
or changed features malfunctioning.
Dewald
On Dec 17, 10:45 pm, Josh Roesslein wrote:
> I am not sure how beneficial this would really be. Versioning fro
I am not sure how beneficial this would really be. Versioning from
what I understand is for changes to the
API that might break applications that have not yet updated. It
wouldn't really provide any security against bugs/quirks
in Twitter's backend which can cause downtime. So even older versions
m
The yo-yo ride of the retweet API gave me this idea. It depends on
proper versioning of the API by Twitter.
Twitter creates an API call that returns the current working API
version. We query that method and use that version of the API for our
calls.
If something goes down, Twitter simply pushes o
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 wrote:
>
> Hi Marcel-
>
> I'm s
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 wrote:
> The change has been made but it probably hasn't been pushed out yet to
> the fu
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 wrote:
>
> Thanks, but still failing today.
>
--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio
Thanks, but still failing today.
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.c
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/fri
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.
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 dire
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
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
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
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 OAu
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 fami
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
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?
Great news guys, I noticed that the search and oauth API's aren't in
the version one API stream though.
Is this intentional?
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,
Calm it down or I will turn this thread around SO FAST ;) I think the
discussion's over, all.
On Thu, Dec 11, 2008 at 14:09, Stut wrote:
>
> On 11 Dec 2008, at 21:56, itcn wrote:
>>
>>> shrugs<
>>
>> I love when people wander into a discussion without having read any of
>> the history, ask a qu
On 11 Dec 2008, at 21:56, itcn wrote:
shrugs<
I love when people wander into a discussion without having read any of
the history, ask a question specifically to start a fight, and then
act like they're the hero for stopping the drama they started.
kthxbai
I love it when someone doesn't reme
I think you're the one who took it as an attempt to start a fight,
hoss. A difference of opinion isn't the same as an attempt to
instigate. Even if it is, rise above, eh?
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
On Thu, Dec 11, 2008 at 4:56 PM, itcn wrote
>shrugs<
I love when people wander into a discussion without having read any of
the history, ask a question specifically to start a fight, and then
act like they're the hero for stopping the drama they started.
kthxbai
On Dec 11, 4:48 pm, Cameron Kaiser wrote:
> > > > You'll see the behavior is
> > > You'll see the behavior is erratic and we can't get consistent results
> > > for any ids; the entire XML version of the API seems to have crashed
> > > over the past couple days.
> >
> > Did you also see Alex's replies where they're working on it?
>
> Yes I did, that's why I wish you would h
Of course that's unrealistic; but the point of this thread is to leave
older versions of the API available for several months before new
updates are rolled out, which may potentially introduce bugs. So my
point was, that would be awesome!
On Dec 11, 4:34 pm, "Abraham Williams" <4bra...@gmail.com
To lighten the mood
Twitter can you give us at least 48 hours notice before new bugs are created
so we know what unexpected responses to expect? KTHXBI!
On Thu, Dec 11, 2008 at 15:30, Cameron Kaiser wrote:
>
> > > > In the mean time, can you give us some kind of heads up (ideally a
> > > >
Yes I did, that's why I wish you would have read the other threads
where it was mentioned before questioning me on it.
On Dec 11, 4:30 pm, Cameron Kaiser wrote:
> > > > In the mean time, can you give us some kind of heads up (ideally a
> > > > couple days warning or something) if you are plannin
> > > In the mean time, can you give us some kind of heads up (ideally a
> > > couple days warning or something) if you are planning to make a change
> > > that could, as soon as it goes live, break an app? _So we can try to
> > > be ready for it when you flip the switch :)
> >
> > But they *do* d
That's definitely a bug, and we're working on the fix right now.
On Thu, Dec 11, 2008 at 13:30, Ed Finkler wrote:
>
> FWIW, I'd call that a bug, not an API change. I can't imaging that's
> on purpose. Maybe I'm wrong!
>
> --
> Ed Finkler
> http://funkatron.com
> AIM: funka7ron
> ICQ: 3922133
> S
FWIW, I'd call that a bug, not an API change. I can't imaging that's
on purpose. Maybe I'm wrong!
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
On Thu, Dec 11, 2008 at 4:28 PM, itcn wrote:
>
> Cameron, this has already been mentioned in several other threads,
Cameron, this has already been mentioned in several other threads, but
compare a couple of XML results:
http://twitter.com/users/show/id.xml
http://twitter.com/users/show/twitterapi.xml
You'll see the behavior is erratic and we can't get consistent results
for any ids; the entire XML version of t
Sure can. In fact, we gave people nine days notice for the change to
the response body of /account/verify_credentials. But I don't predict
any more changes of this sort to the API in this "version", looking at
our list of outstanding issue requests.
On Thu, Dec 11, 2008 at 13:14, Alex wrote:
>
> In the mean time, can you give us some kind of heads up (ideally a
> couple days warning or something) if you are planning to make a change
> that could, as soon as it goes live, break an app? So we can try to
> be ready for it when you flip the switch :)
But they *do* do this. Stuff slips thr
That makes sense.
In the mean time, can you give us some kind of heads up (ideally a
couple days warning or something) if you are planning to make a change
that could, as soon as it goes live, break an app? So we can try to
be ready for it when you flip the switch :)
Thanks. Appreciate all that
Versioning is a major part of the design of the next version of the
Twitter API (a rewrite, essentially). We know it's been long since
missing from the API, and we're eager to fix that. Making life hard
for developers definitely isn't our goal.
On Thu, Dec 11, 2008 at 12:05, Alex wrote:
>
> Th
> That would be awesome! Our entire Twitter-based website and
> application has been dead in the water since the API was changed
> abruptly 3 days ago and stopped supporting users/show XML requests.
> It was working fine before Tuesday; had we had some advance notice
> that the Twitter API would
That would be awesome! Our entire Twitter-based website and
application has been dead in the water since the API was changed
abruptly 3 days ago and stopped supporting users/show XML requests.
It was working fine before Tuesday; had we had some advance notice
that the Twitter API would no longer
The Twitter ecosystem has grown quite a bit, and a lot of users are
relying on the API (and third party software) nowadays.
Small API changes can break these applications, and could possibly
affect thousands of Twitter users.
I understand that the API will need to evolve - but can you please
con
43 matches
Mail list logo
