[twitter-dev] Re: Where We're At With Location
I might look at swapping over to the reverse geocoder provided by geoapi.com as an alternative to the google maps api which has a tendency to give some weird results. On Dec 24, 9:04 am, Marcel Molina mar...@twitter.com wrote: For the last few months, the Platform team has been really excited about all the possibilities that open up when geo is added throughout our APIs. Recently, we've launched support for geo tagging tweets (http://bit.ly/4pFY77) as well as the imminent availability of a local trends API (http://bit.ly/12M84f). We're psyched about geo and today we have some big news. Twitter has acquired Mixer Labs, creators of GeoAPI (http://geoapi.com/). As Ev just said over on our main blog (http://bit.ly/88nZ6B), the team from Mixer Labs will be joining Twitter. We're currently looking at how to integrate the work Mixer Labs has done with the Twitter Platform to provide powerful new possibilities. We wanted to give everyone here a heads up on the good news. We look forward to supporting lots more geo functionality. Start your engines! -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: Loose ends for List and Retweet APIs
Retweets of Me (http://apiwiki.twitter.com/Twitter-REST-API-Method%3A- statuses-retweets_of_me) * add details about who retweeted your tweets, only needs to be first retweeter and a count of total number of times retweeted. Lists: * add list details node (eg. same as GET list_id method) to other lists methods such as 'GET list statuses', 'GET list members', 'GET list subscribers' - would allow me to replicate the individual 'list pages' like on twitter.com without the need to make additional api calls (not a huge issue with the forthcoming rate limit increase.) On Dec 19, 6:09 am, Marcel Molina mar...@twitter.com wrote: 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 Teamhttp://twitter.com/noradio
[twitter-dev] Re: URLification
I've recently switch to using this regex for pulling out links,
haven't spotted any issues with any extra characters surrounding the
links as yet.
/(?i)\b((?:[a-z][\w-]+:(?:\/{1,3}|[a-z0-9%])|www\d?[.])(?:[^\s()]+|\
([^\s()]+\))+(?:\([^\s()]+\)|[^`!()\[\]{};:\'.,?«»“”‘’\s]))/
It was posted by @gruber to his twitter feed a couple of days after
his post that Chad linked to above.
On Dec 19, 3:48 am, Chad Etzel jazzyc...@gmail.com wrote:
This might be relevant to your
interests:http://daringfireball.net/2009/11/liberal_regex_for_matching_urls
Something definitely changed in the twitter web front-end code which
is borking url matching as of a month or so ago...
-Chad
On Fri, Dec 18, 2009 at 2:44 AM, Harshad RJ harshad...@gmail.com wrote:
Although not an API issue, it might be good to track it as such, because
Twitter clients can then follow exactly the same policies that Twitter web
interface does.
If there is a standard regular expression that can be used for detecting a
URL, it could be published as a guideline in the API documentation for
consistency between all clients.
cheers,
Harshad
On Fri, Dec 18, 2009 at 2:45 AM, Raffi Krikorian ra...@twitter.com wrote:
its not an API issue -- the API doesn't do any auto-URLification.
however, i'll pass this thread off to the web client team.
On Thu, Dec 17, 2009 at 1:13 PM, dbasch dba...@gmail.com wrote:
I agree. I searched the issues db and didn't find it. Not sure if it
belongs as an API issue but I submitted it anyway.
http://code.google.com/p/twitter-api/issues/detail?id=1298
--
Harshad RJ
http://hrj.wikidot.com
[twitter-dev] Re: Bad ssl certs on some servers for api.twitter.com/1 ?
This could possibly be related, I recently switched from using https://twitter.com to https://api.twitter.com and found that the majority of my cURL calls (via php) to the api started failing, although no other parts of my function changed. Out of curiosity I changed it to http://api.twitter.com and haven't had the issue since. On Nov 16, 10:46 am, 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
[twitter-dev] Re: Lists API for Subscriptions
+1 I've just started adding Lists to Hahlo.com and found this same thing. Based on the description in the docs I was expecting: /user/lists.format to be just the lists the user created /user/lists/subscriptions.format to be the lists the user created + those they are following (as it is on twitter.com), not just the ones they are following any chance of getting a combined my lists + lists I follow (or changing the /subscriptions response) to eliminate the need for multiple API calls? On Nov 2, 4:27 am, Eric Woodward e...@nambu.com wrote: Thanks for that. It would be great to combine them and reflect ownership in the response data set. This requires two API calls for what will be requested each time to show both sets together, which you on twitter.com. I assume others will tend to show both sets at the same time as well. --ejw Eric Woodward Email: e...@nambu.com On Oct 31, 3:01 pm, twittelator and...@stone.com wrote: Whoops - what I meant to say was: :user//lists/subscriptions.:format will get the lists a 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:52 pm, Eric Woodward e...@nambu.com wrote: Anyone seeing an issue with a method to get a list of a user's list subscriptions? The following: curl -u ejwc:[password] http://twitter.com/ejwc/lists.xml; only returns the three test lists that I have created, while the same URL on Twitter's website: https://twitter.com/ejwc/lists returns my three test lists, and the 5+ lists I am following. Any suggestions? I have only just started getting a response for the API methods in the last day or so and only getting familiar with them. Any help would be appreciated. --ejw Eric Woodward Email: e...@nambu.com
[twitter-dev] Re: New Twitter feature API coming soon: Lists
Nice stuff! Glad I didn't spend a heap of time developing my own list/group solution for Hahlo, instead I can just drop in the API. sweet. On Oct 1, 9:13 am, Marcel Molina mar...@twitter.com wrote: 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 Teamhttp://twitter.com/noradio
[twitter-dev] Has replies/mentions behavior changed again or it is broken?
Just checking out my @ mentions and noticed there are a whole bunch missing, took a little while to register what was going on, but it looks like only tweet that begin with @username are being returned - this is happening both on twitter.com and via the API. Anyone else notice this, and is it a bug or a feature...
[twitter-dev] Re: Streaming API -- Recheck your clients -- post DDoS cleanup
What about those using the regular API, via both Basic Auth and OAuth, is there anything at all we can do to stop getting endless 408's ? I'm guessing that since even twitter.com itself is still very inconsistent, for lack of a better word, theres probably nothing much more we can do than just wait. On Aug 7, 7:22 am, Shannon Clark shannon.cl...@gmail.com wrote: Not specific to only developers but at the momenthttp://search.twitter.com is not loading on my iPhone though search via an iPhone app (twitterfon is what I tried) is working. Shannon Sent from my iPhone On Aug 6, 2009, at 2:19 PM, John Kalucki jkalu...@gmail.com wrote: Some users were unable to connect to the Streaming API at various times during the DDoS. This has been fixed for the majority of Streaming API clients. The connection count is now approaching yesterday's count. If your Streaming API client is still receiving 409 redirects, connection timeouts, or any other issue that started today, please contact me with your account name and IP address, and I'll work to resolve the issue. -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc.
[twitter-dev] Has something with OAuth changed?
Everyone just magically got logged out of my hahlo4 beta, which was working fine an hour ago, and now when they reauthorize its not sticking. OAuth login works fine, redirect back to hahlo4, but all api calls are returning 401 status codes. Saw mention in another topic regarding whether twitter.com or www.twitter.com should be used when making api call, all my calls are currently using https://twitter.com Anyone else experiencing anything similar?
[twitter-dev] Re: Has something with OAuth changed?
Thanks for the super speedy response Matt. On Jul 10, 9:26 am, Matt Sanford m...@twitter.com wrote: Hi all, Some changes were just deployed and it looks like there may be a bug. I'm looking into it now … hold tight and I'll update you all when I know more. Thanks; – Matt Sanford / @mzsanford Twitter Dev On Jul 9, 2009, at 4:25 PM, dean.j.robinson wrote: Everyone just magically got logged out of my hahlo4 beta, which was working fine an hour ago, and now when they reauthorize its not sticking. OAuth login works fine, redirect back to hahlo4, but all api calls are returning 401 status codes. Saw mention in another topic regarding whether twitter.com orwww.twitter.com should be used when making api call, all my calls are currently using https://twitter.com Anyone else experiencing anything similar?
[twitter-dev] Re: Has something with OAuth changed?
Awesome, thanks Matt, seems to be all working normally here too. On Jul 10, 10:37 am, Matt Sanford m...@twitter.com wrote: Hi all, The issue has been fixed and from my testing it looks like things are back to normal. Sorry for the disruption; – Matt Sanford / @mzsanford Twitter Dev On Jul 9, 2009, at 4:38 PM, dean.j.robinson wrote: Thanks for the super speedy response Matt. On Jul 10, 9:26 am, Matt Sanford m...@twitter.com wrote: Hi all, Some changes were just deployed and it looks like there may be a bug. I'm looking into it now … hold tight and I'll update you all when I know more. Thanks; – Matt Sanford / @mzsanford Twitter Dev On Jul 9, 2009, at 4:25 PM, dean.j.robinson wrote: Everyone just magically got logged out of my hahlo4 beta, which was working fine an hour ago, and now when they reauthorize its not sticking. OAuth login works fine, redirect back to hahlo4, but all api calls are returning 401 status codes. Saw mention in another topic regarding whether twitter.com orwww.twitter.com should be used when making api call, all my calls are currently using https://twitter.com Anyone else experiencing anything similar?
[twitter-dev] Re: 'verified' attribute in api responses?
awesome... I probably should have looked closer, I only did a quick search of the group and check the api changelog... didn't think to run a request and check On Jun 15, 2:53 pm, Abraham Williams 4bra...@gmail.com wrote: On Sun, Jun 14, 2009 at 23:17, dean.j.robinson dean.j.robin...@gmail.comwrote: Any plans to add an attribute to the API responses to indicate if a user is a verified user? Would be nice if this info was available so that it could be displayed against the appropriate tweeters as needed. Already added. See example:http://twitter.com/users/show.xml?screen_name=Mashable -- Abraham Williams | Community |http://web608.org Hacker |http://abrah.am|http://twitter.com/abraham Project |http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] 'verified' attribute in api responses?
Any plans to add an attribute to the API responses to indicate if a user is a verified user? Would be nice if this info was available so that it could be displayed against the appropriate tweeters as needed. Also swapped my own groups implementation in Hahlo4 for the saved_searches api last night - it works beautifully, thanks for adding it to the api. :)
[twitter-dev] Re: Streaming API Terms Of Service change - multiple simultaneous logins discouraged
Nice work guys, talk about the firehose has been floating around for ages, great to see it finally appear and with numerous variants available (thats a bonus). I personally don't have any use for it (yet) but I'm sure it'll please quite a few. On May 10, 2:04 pm, John Kalucki jkalu...@gmail.com wrote: Note: The Streaming API is currently under a limited alpha test, details below. Multiple concurrent connections from the same account are discouraged on the Streaming API. Starting on or after the afternoon of Monday, May 11th (22:00:00 11-May-2009 UTC) the service will gently enforce this policy. A later release will fully enforce this policy. Subsequent connections from the same account will cause previously established connections to be disconnected. In some cases, this might cause operational difficulties for developers who are using the restricted resources. For example, a developer's staging test might knock that developer's production / gardenhose feed offline. Non-production uses should connect to the / spritzer resource with a secondary account to avoid these conflicts. We may, on a case-by-case basis, grant exceptions to this policy as we work through the alpha test. We will attempt to balance ease-of-use, resource consumption and abuse prevention. -John Kalucki - Services, Twitter Inc.http://twitter.com/jkalucki Important Alpha Test Note: The Streaming API (aka Hosebird) is currently under an alpha test. All developers using the Streaming API must tolerate possible unannounced and extended periods of unavailability, especially during off-hours, Pacific Time. New features, resources and policies are being deployed on very little, if any, notice. Any developer may experiment with the unrestricted resources and provide feedback via this list. Access to restricted resources is extremely limited and is only granted on a case-by-case basis after acceptance of an additional terms of service document. Documentation is available:http://apiwiki.twitter.com/Streaming-API-Documentation.
[twitter-dev] Re: Deprecation of following and notification elements
I'll admit I'm a little disappointed that the info won't be part of the user objects anymore (will have to rethink some of my planned features... ie. won't be able to dynamically show/hide the dm button next to tweets if it means I need an additional api call for each user) instead relying on another api call, but I'm sure you guys have your reasons. Thanks for the advanced warning :) On May 12, 7:18 am, Doug Williams d...@twitter.com wrote: Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. The defects report that methods returning user objects (see users/show for an example [3]) are returning incorrect or invalid values for the following element. The fix for this inconsistency is in fact non trivial [4]. The problem lies within the interaction of the application logic, caching layer and database design. The persistent data behind following and notification values are separate from the user data in our architecture, so to keep these elements valid in cache alongside user objects adds a large amount of complexity. Developers made it obvious that these data are a priority and we want to ensure they available. We also want to guarantee they are accurate and that performance remains good. Given the problems explained above, we are going to be making a number of changes to the API so that you can rely on the following or notification data. Deprecations: The following elements are to be removed from all returned user objects returned by the API: 1) following 2) notifications This deprecation will not occur until we finish the following: Additions: To continue to provide access to this data we will be creating a new method: Issue 532 [4] outlines the need to perform a mutual following lookup. We will use a method similar to that described in this issue to deliver following, followedby, notification and pending (in the case of protected users) data with a single call. We realize this change will cause an increase in API usage for some applications. Therefore we are going to increase the default API rate limit across the board. This should help absorb some of the costs for applications attempting to do interesting things with social graph data. The number will be somewhere between 101 and 200 calls but we still need to look at growth projections and current hardware capacity before settling on a definite number. We plan to begin work on this relatively soon with the fix coming in a few weeks. We do not have a planned ship date at this time but will communicate specifics with developers as they are determined. We anticipate the new number of calls and a documented schema for the new method will be made available before the new method ships. Please watch this thread and @twitterapi for the incremental details. 1.http://code.google.com/p/twitter-api/issues/detail?id=419 2.http://code.google.com/p/twitter-api/issues/detail?id=474 3.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show 4.http://www.jamesshuggins.com/h/tek1/first_computer_bug_large.htm 5.http://code.google.com/p/twitter-api/issues/detail?id=532 Thanks, Doug -- Doug Williams Twitter Platform Supporthttp://twitter.com/dougw
[twitter-dev] feature request/enhancement for friendships/exists
So, if I've got two users user_a and user_b the method currently works like this (from api wiki): Tests for the existence of friendship between two users. Will return true if user_a follows user_b, otherwise will return false. Now, if I also wanted to know if user_b follows user_a I currently need to do an additional api call, it would be great if both could be done with one call. I'm looking at using this to determine, a. if you can send a DM to the user you're trying to, and b. if that user is then going to be able to reply. Something like http://twitter.com/friendships/mutual.format taking the same two params user_a and user_b, and perhaps returning something like: followingtrue/following (ie. user_a follows user_b) followedbytrue/followedby (ie. user_b follows user_a) also, it'd be nice if this post doesn't get deleted, without explanation, like the last two I've posted. :)
[twitter-dev] Re: feature request/enhancement for friendships/exists
actually only one of the two was deleted, sorry my bad, its just not showing up in my google groups recent activity. On Apr 25, 1:56 pm, dean.j.robinson dean.j.robin...@gmail.com wrote: So, if I've got two users user_a and user_b the method currently works like this (from api wiki): Tests for the existence of friendship between two users. Will return true if user_a follows user_b, otherwise will return false. Now, if I also wanted to know if user_b follows user_a I currently need to do an additional api call, it would be great if both could be done with one call. I'm looking at using this to determine, a. if you can send a DM to the user you're trying to, and b. if that user is then going to be able to reply. Something like http://twitter.com/friendships/mutual.format taking the same two params user_a and user_b, and perhaps returning something like: followingtrue/following (ie. user_a follows user_b) followedbytrue/followedby (ie. user_b follows user_a) also, it'd be nice if this post doesn't get deleted, without explanation, like the last two I've posted. :)
[twitter-dev] Re: oAuth is BACK!
I posted this yesterday, but the post appeared to vanish into the ether, during the OAuth 'outage' my dev version of Hahlo 4 (which uses OAuth) continued to work fine, is this because I was already logged in and the token was still valid? I'm guessing if I'd logged out/ unauthorized then I wouldn't have been able to log back in. Not that it matters now though, good work in getting things back up again so quickly :) Personally the missing user info in the callback is no big deal for me, as I'm calling verify_credentials to get the full profile anyway. (Took me quite a while to even notice it was being returned...) On Apr 24, 8:31 am, Doug Williams d...@twitter.com wrote: Nic, We are aware that the current lack of dynamic callback is limiting for development. In the meantime, we wanted to get OAuth support restored while we (and the OAuth consortium) develop a fix for this vulnerability. We intend to address this constraint in the near future. Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw On Thu, Apr 23, 2009 at 3:19 PM, Dr Nic dr...@mocra.com wrote: If we cannot run-time configure the callback URI then we'll need multiple application registrations for development + production? (assuming the need for absolute URIs) Cheers Nic On Apr 24, 7:38 am, Matt Sanford m...@twitter.com wrote: Hi there, I totally forgot about that change. Since the oauth callback is unsigned it was too easy to forge that data. I'm trying to find a good way to include it but right now calling verify_credentials is the best work around. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 02:31 PM, mikehar wrote: However, the callback no longer contains the user info. Why did this change? You can get the user info by calling account/ verify_credentials.format. On Apr 23, 2:20 pm, @pud pkap...@gmail.com wrote: Great work @al3x and the rest of the Twitter crew! My oAuth seems to be working once again: http://fast140.com/oauth/authorize
[twitter-dev] Re: Request for documentation review
I've had a quick look, looks good so far, nicely organised, plenty of info etc. Will go through it more closely during my lunch break and let you know if I spot anything. top work. On Apr 15, 3:35 am, Doug Williams d...@twitter.com wrote: Ahmed and Chad, I'm rolling in all of those suggestions right now. Thank you both for thorough perusal. Any REST guys out there that can offer the similar insight? Doug Williams Twitter API Supporthttp://twitter.com/dougw On Tue, Apr 14, 2009 at 9:50 AM, Chad Etzel jazzyc...@gmail.com wrote: A note on the Trends page: / QUOTE ***/ Twitter Search API Method: trends Returns the top ten queries that are currently trending on Twitter. The response includes the time of the request, the name of each trending topic, and the url to the Twitter Search results page for that topic. / END QUOTE ***/ Returns the top ten *queries* that are currently trending on Twitter is inaccurate. They are the top ten trends being posted by people on twitter. It should really be the ... top ten (phrases/words/topics) that are currently trending on Twitter. -Chad On Tue, Apr 14, 2009 at 12:40 PM, Chad Etzel jazzyc...@gmail.com wrote: More feedback about the Search API section: # Mentioning a user: http://search.twitter.com/search.atom?q=to%3Amzsanford to:user in Search-land means that the tweet physically begins with @user. This would be the stricter reply definition. I would change Mentioning to Replies to a user or Strict Replies to a user # Referencing a user:http://search.twitter.com/search.atom?q=%40biz Referencing should really be Mentioning here since that is in line with the nomenclature of mentions in Twitter/REST-land. # Combine any of the operators together: http://search.twitter.com/search.atom?q=happy+hour+near%3ASF The Search API does *NOT* support the near:location operator (even though the website does). You must send in a geocoded lat/lang/radius style argument in order to accomplish this with the API. Ask Matt about the official format. # Originating from an application: http://search.twitter.com/search.atom?q=landingfrom:tweetie 4 things: 1) searching for an application uses the source: operator, not from: 2) you should mention somewhere that you *cannot* just search for tweets from a source, but that you must at least pass in some other keyword to search along with the source: operator. 3) On a more general note, the spaces should be urlencoded as well. It would probably help to mention somewhere in the doc that all queries must be urlencoded before sending them. 4) For some reason the link in this example does not actually go to that query. Other thoughts: Where are the Optional Arguments like since_id, max_id, rpp, and page ? I believe I was told by Matt that queries are actually limited to 138 characters since it counts the q= characters in the request as part of the query. That should probably be noted. I'll have a look at the REST sections later, but I don't exercise those as heavily, so I might not be the best to review it. -Chad On Mon, Apr 13, 2009 at 7:11 PM, Doug Williams d...@twitter.com wrote: Coderz, I am refactoring the API documentation [1] to make it friendlier on the eyes and easier on new developers. Please give it a once over and reply with any of errors, addition requests, or suggestions. We will be using these new docs officially in a few days (linked from the apiwiki.twitter.com) once any glaring omissions and/or errors are addressed. My goal is to make the documentation more robust and example laden to help new developers get going without needing help. Suggestions and critism along those lines is welcome. A final plea for help: If you have some spare time and examples to borrow from, please send a...@twitter.com any code/instructions that I can then paste into method body to help new devs get started. Basic Hello World! style usage examples for each method would go a long way to curbing new developer problems. Be sure to include a link to any libraries your example is using. Working full length example code hosted on github would be preferred. 1.http://apiwiki.twitter.com/Twitter-API-Documentation Thanks, Doug Williams Twitter API Support http://twitter.com/dougw
[twitter-dev] Re: Changes for April 8, 2009
Especially with regards to the deprecation of certain things. I totally missed the topic about the deprecation of the since param which was only posted on the 8th. Reading it now it said: Please use the next few days to update your application to use the since_id parameter if it is currently using since/If-Modified-Since. This deprecation will happen when the deploy hits our server in the middle to end of the week. ...didn't really get the next few days though... since it seems to have been removed on the 9th Although it does explain why I've been getting constant errors in Hahlo 3 (which uses 'since') and not Hahlo 4 (which uses 'since_id') On Apr 10, 2:38 am, Peter Denton petermden...@gmail.com wrote: Seems like a lot of people are on gmail here. I think a google alert would work nice, that way we could get a stand out email. On Thu, Apr 9, 2009 at 9:14 AM, Carlos Crosetti carlos.crose...@gmail.comwrote: I got mu friends timelines btoken today because you changed from POST to get, now I aligned properly. Would be nice from you tellling this changes in advance. Areyou doing release management? Best regards,, Carlos On Thu, Apr 9, 2009 at 12:20 PM, Matt Sanford m...@twitter.com wrote: Hi all, Sorry for the late email but the deploys yesterday ran late and we didn't get a chance to compile the change log. And a doozy of a change log it is with 10 entries. Other things were deployed as well but here are the 10 API-facing changes: * Changed (REST): The since parameter and If-Modified-Since header are no longer supported. » Discussed athttp://bit.ly/19JZme * Fixed (REST): Methods documented as requiring GET were allowing POST and not counting the rate limit correctly. These methods now require GET and return an error message if POST is used. » Discussed athttp://bit.ly/o38Dl * Fixed (REST): The deprecated email parameter was being silently ignored, an error is now returned. » Discussed athttp://bit.ly/4APnTx » See:http://code.google.com/p/twitter-api/issues/detail?id=353 * Fixed (REST): The /users/show.$fmt method now thorws a 404 error if no recognized parameters are given. » This is a part of the previous issue and many complaints about the user @show being returned as a default * Fixed (OAuth): Rate limiting was incorrectly by IP only when using the Authenitcation header. This has been corrected. » See:http://code.google.com/p/twitter-api/issues/detail?id=376 * Fixed (OAuth): Error messaging for OAuth clients is now more detailed. » See:http://code.google.com/p/twitter-api/issues/detail?id=403 * Fixed (REST): Direct message objects were not returning the large user representations in json responses. They will now begin doing so. * Fixed (REST): Calls to direct message XML methods were incorrectly displaying the nilclass root tag. This has been corrected. » See:http://code.google.com/p/twitter-api/issues/detail?id=406 * Feature (REST): Added /direct_messages/show/$id.$fmt method (where $id is the direct message id and $fmt is xml or json) » See:http://code.google.com/p/twitter-api/issues/detail?id=369 » Note: Still needs to be added to the documentation * Feature (OAuth): Added provisional support for Sign in via Twitter for OAuth applications. An official annoucement will follow after full support is available. » More on this to come in subsequent mails. I need to get another piece in place first. There were also a collection of other fixes which included fixing the Sign out link on the OAuth authorization page. Thanks; — Matt Sanford / @mzsanford -- Carlos Crosetti -- Peter M. Dentonwww.twibs.com i...@twibs.com Twibs makes Top 20 apps on Twitter -http://tinyurl.com/bopu6c
[twitter-dev] verify_credentials not returning full user data for some users
I noticed this because I've got some code that checks the utc_offset and noticed that it was missing. For my hahlo account verify_credentials is returning this (appears to be missing colours, utc_offset, fav counts etc etc): ?xml version=1.0 encoding=UTF-8? user id7097682/id nameHahlo.com/name screen_namehahlo/screen_name locationNewcastle, Australia/location descriptionThe best iPhone/touch style Twitter app. Hahlo 4 will be oAuth-tastic./description profile_image_urlhttp://s3.amazonaws.com/twitter_production/ profile_images/53694164/favicon_normal.png/profile_image_url urlhttp://hahlo.com/url protectedfalse/protected followers_count1097/followers_count status created_atTue Mar 31 00:52:42 + 2009/created_at id1421396597/id textgreat news from twitter, all @replies are now part of the replies timeline, effective immediately, you don't need to change a single thing/text sourcelt;a href=quot;http://dev.hahlo.com/ quot;gt;#948;.hahlolt;/agt;/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name /status /user for my deanjrobinson account it returns this: ?xml version=1.0 encoding=UTF-8? user id782566/id nameDean Robinson/name screen_namedeanjrobinson/screen_name locationNewcastle, Australia/location description/description profile_image_urlhttp://s3.amazonaws.com/twitter_production/ profile_images/54336181/fie-12_normal.png/profile_image_url urlhttp://www.deanjrobinson.com/url protectedfalse/protected followers_count375/followers_count profile_background_colorFF/profile_background_color profile_text_color323232/profile_text_color profile_link_color676767/profile_link_color profile_sidebar_fill_colorF5F5F5/profile_sidebar_fill_color profile_sidebar_border_colorEE/profile_sidebar_border_color friends_count97/friends_count created_atTue Feb 20 08:02:11 + 2007/created_at favourites_count65/favourites_count utc_offset36000/utc_offset time_zoneSydney/time_zone profile_background_image_urlhttp://s3.amazonaws.com/ twitter_production/profile_background_images/1486932/twitterbg.jpg/ profile_background_image_url profile_background_tilefalse/profile_background_tile statuses_count2157/statuses_count notifications/notifications following/following status created_atThu Apr 02 22:55:57 + 2009/created_at id1441582913/id texthmmm, installed littlesnapper update, and now I've got four copies of every screenshot... I think thats a bug./text sourcelt;a href=http://www.hahlo.com/gt;Hahlolt;/agt;/ source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name /status /user Is this connected to the recent change that adds the full user object to all api calls?
[twitter-dev] Will saved searches be available from the api in the future?
Hi all, Saw a tweet earlier from @bs about 'saved searches' being a new feature on twitter that is now available for some users. This is one of the features I had been planning on adding to Hahlo4, so I'd like to know if its something that we might be able to do via the api in the future (perhaps part of the 'new' api when that arrives?) as an alternative to me writing my own implementation. also, while I'm here, how would one go about getting one of those little twitter definition things in the sidebar, just curious :) must say I'm really liking all the incremental changes lately (facebook must be too since they're shamelessly copying you guys with their silly stream thingo) cheers Dean
[twitter-dev] oauth not working via https://twitter.com
For example: https://twitter.com/oauth/authorize?oauth_token=OMxcOPndHoO57JMFURt8GyzKpnREj9oKf6aG6f3pU that url doesn't work (returns stanard twitter page not found), but this one does http://twitter.com/oauth/authorize?oauth_token=OMxcOPndHoO57JMFURt8GyzKpnREj9oKf6aG6f3pU This doesn't always seem to be the case, but any thoughts on why?
[twitter-dev] Re: oauth not working via https://twitter.com
Thanks for the speedy response Matt. Much appreciated. On Mar 5, 10:49 am, Matt Sanford m...@twitter.com wrote: Hi all, This is related to the login error (http://status.twitter.com/post/83602310/problems-logging-in ) and people are working on it. Thanks; — Matt Sanford On Mar 4, 2009, at 03:32 PM, dean.j.robinson wrote: For example: https://twitter.com/oauth/authorize?oauth_token=OMxcOPndHoO57JMFURt8G... that url doesn't work (returns stanard twitter page not found), but this one does http://twitter.com/oauth/authorize?oauth_token=OMxcOPndHoO57JMFURt8Gy... This doesn't always seem to be the case, but any thoughts on why?
Re: PHP OAuth Example Code
An enormous thank you from me too! Every other library/example I've found either didn't appear to work or was a clear a mud to me. thanks again for sharing. On Feb 15, 1:03 pm, Abraham Williams 4bra...@gmail.com wrote: I wrote up some example code to get OAuth working in PHP. Code:http://github.com/poseurtech/twitteroauth Live example:http://twitter.abrah.am Docs:https://docs.google.com/View?docID=dcf2dzzs_2339fzbfsf4 Feel free to contact me if you have any questions/find bugs/etc. I'm working on convertinghttp://github.com/jdp/twitterlibphpto use OAuth and should have that complete in a few days. Abraham @poseurtech -- Abraham Williams |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [x] blogable [ ] ask first [ ] private. Sent from: Madison Wi United States.
update_profile_colors lag?
I'm in the process of adding a screen to Hahlo to allow users to change their twitter profile colors on the fly, the post to the api works, and returns the updated user info as expected, and when I re- retrieve a user profile from the api it too reflects the changes I submitted, but the colors aren't changing when I view the full profile at twitter.com. Eg. I changed the background color to f00, and the link color to ff in Hahlo Viewing http://twitter.com/users/show/hahlo_test.xml the change worked, but viewing twitter.com/hahlo_test to default colors remain. When I login to twitter.com and got to settings-design-colors the defaults are also returned not the value I specified. Is there a some sort of lag between the api and the main site updating or is it that I'm just getting a cached page(s) Thanks Dean
Re: Expect Header Issue for .NET developers
Started getting reports from users yesterday that they couldn't login
to hahlo.com.
Turns out that the check I run against verify credentials was also
returning code 417 instead of the usual/expected 200, so even though
the check was working to hahlo is looked like it was failing, changed
my check to include code 417 and now its working again.
Strangely though, a local dev copy of Hahlo 4, which also checks
verify credentials and also only expects a 200 response, is still
working fine..,
On Dec 25, 6:57 am, Tom Morris t...@tommorris.org wrote:
On Dec 24, 4:31 am, JakeS jakesteven...@gmail.com wrote:
Looks like twitter is updating something and their servers are
returning error 417 for a lot of requests. I looked into it and found
that .NET automatically includes an Expect header containing 100-
continue on every request unless you specifically tell it not to.
So for any .NET devs having trouble, you can set
System.Net.ServicePointManager.Expect100Continue = false before making
your request to get past this issue.
A lot of libraries follow this behaviour. A Twitter app I wrote in PHP
a while back has been logging 417s most of today. I logged in and
added:
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:'));
Other libcurl-based libraries may be affected. There are plenty of
reports about 417 and Expect on the cURL website -http://curl.haxx.se/
- and on the websites of particular language bindings.
--
Tom Morris (@tommorris)
http://tommorris.org
Re: INCOMPATIBILITY ALERT: response body of /account/verify_credentials changing Dec 10th
Thanks Alex, looks great. I'm playing with it now and am looking to use it to replace the additional show/user.json call that I previously needed. There are a few properties that are in user/show but not in the verify_credentials method, I was wondering if there are plans to include these in a future update, or if I'll need to continue using two separate calls as I am now. Those that are missing/not returned are: - friends_count - utc_offset - profile_text_color - statuses_count - profile_link_color - notifications - following - time_zone - created_at - profile_sidebar_fill_color - favourites_count - profile_sidebar_border_color - profile_background_color thanks On Dec 11, 1:07 pm, Alex Payne [EMAIL PROTECTED] wrote: Just a reminder: today was the day for this change to go live, and it just went live. On Thu, Dec 4, 2008 at 12:42, Brooks Bennett [EMAIL PROTECTED] wrote: I agree, this is a great change. On Dec 3, 11:07 pm, dean.j.robinson [EMAIL PROTECTED] wrote: return the representation of the authenticated user does that mean that the response will be the same as if we calledhttp://twitter.com/users/show/id.format for the authenticated user? If so that would be awesome and means I could completely eliminate some of the extra api calls that I'm making. Doesn't matter too much either way though, since both Hahlo 3.1 and Hahlo 4 (which I've recently begun work on) both currently use the http status for confirmation. thanks for the heads up. On Dec 3, 1:14 pm, Alex Payne [EMAIL PROTECTED] wrote: As perhttp://code.google.com/p/twitter-api/issues/detail?id=173we'll be changing the /account/verify_credentials method to return the representation of the authenticated user. Because some applications depend on the contents of this response, we're delaying this change until December 10th, 2008. Please update your applications to verify by response code, not by the response body for this method. If you get a 200 back, you're verified. If you get a 401 back, you're not. If you can't ship an update in 8 days, please let us know and we'll push the date out further. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: INCOMPATIBILITY ALERT: response body of /account/verify_credentials changing Dec 10th
that would be brilliant, it would allow me to completely eliminate the additional api call I'm using, while making sure I can still keep users profile settings up to date on each login. no rush though, thanks in advance :) On Dec 11, 2:34 pm, Alex Payne [EMAIL PROTECTED] wrote: I can have it return the extended version of the User object, sure. On Wed, Dec 10, 2008 at 18:26, dean.j.robinson [EMAIL PROTECTED] wrote: Thanks Alex, looks great. I'm playing with it now and am looking to use it to replace the additional show/user.json call that I previously needed. There are a few properties that are in user/show but not in the verify_credentials method, I was wondering if there are plans to include these in a future update, or if I'll need to continue using two separate calls as I am now. Those that are missing/not returned are: - friends_count - utc_offset - profile_text_color - statuses_count - profile_link_color - notifications - following - time_zone - created_at - profile_sidebar_fill_color - favourites_count - profile_sidebar_border_color - profile_background_color thanks On Dec 11, 1:07 pm, Alex Payne [EMAIL PROTECTED] wrote: Just a reminder: today was the day for this change to go live, and it just went live. On Thu, Dec 4, 2008 at 12:42, Brooks Bennett [EMAIL PROTECTED] wrote: I agree, this is a great change. On Dec 3, 11:07 pm, dean.j.robinson [EMAIL PROTECTED] wrote: return the representation of the authenticated user does that mean that the response will be the same as if we calledhttp://twitter.com/users/show/id.formatfor the authenticated user? If so that would be awesome and means I could completely eliminate some of the extra api calls that I'm making. Doesn't matter too much either way though, since both Hahlo 3.1 and Hahlo 4 (which I've recently begun work on) both currently use the http status for confirmation. thanks for the heads up. On Dec 3, 1:14 pm, Alex Payne [EMAIL PROTECTED] wrote: As perhttp://code.google.com/p/twitter-api/issues/detail?id=173we'll be changing the /account/verify_credentials method to return the representation of the authenticated user. Because some applications depend on the contents of this response, we're delaying this change until December 10th, 2008. Please update your applications to verify by response code, not by the response body for this method. If you get a 200 back, you're verified. If you get a 401 back, you're not. If you can't ship an update in 8 days, please let us know and we'll push the date out further. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: INCOMPATIBILITY ALERT: response body of /account/verify_credentials changing Dec 10th
return the representation of the authenticated user does that mean that the response will be the same as if we called http://twitter.com/users/show/id.format for the authenticated user? If so that would be awesome and means I could completely eliminate some of the extra api calls that I'm making. Doesn't matter too much either way though, since both Hahlo 3.1 and Hahlo 4 (which I've recently begun work on) both currently use the http status for confirmation. thanks for the heads up. On Dec 3, 1:14 pm, Alex Payne [EMAIL PROTECTED] wrote: As perhttp://code.google.com/p/twitter-api/issues/detail?id=173we'll be changing the /account/verify_credentials method to return the representation of the authenticated user. Because some applications depend on the contents of this response, we're delaying this change until December 10th, 2008. Please update your applications to verify by response code, not by the response body for this method. If you get a 200 back, you're verified. If you get a 401 back, you're not. If you can't ship an update in 8 days, please let us know and we'll push the date out further. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
