Yes, API responses will often be returned from cache. As such, there might be brief delays between an activity and the corresponding chain of cache invalidations.
On Thu, Mar 12, 2009 at 11:41, mwm <miguelwmonte...@gmail.com> wrote: > > Hi, > > I'm the developer of TwitteReader and I have remade the architecture > of the communication between the application's host and Twitter, via > API. > > Example and objective: > delete the status 123456 (that I own) and then load the last 20 > friend_timeline messages. > > Before: > > 1. app calls host with statusID = 123456 > 2. host calls http://twitter.com/statuses/destroy/123456.xml > 3. whether or not it is successful, it returns to the app with the > output. > > 4. app calls host for last 20 messages > 5. host calls http://twitter.com/statuses/friends_timeline.xml and > might add page and count (max 20) > 6. also returns with or without messages to the app with the call > output. > > Now (testing): > > 1. app calls host with statusID = 123456 and reload request for last > 20 messages > 2. host calls http://twitter.com/statuses/destroy/123456.xml > 3. host calls http://twitter.com/statuses/friends_timeline.xml > 4. returns xml modified in the end : original xml + output from > destroying > > Being this for destroying or updating. > Thing is, I tested this and also with the version before and have been > having inconclusive results of how the API and XML web service of > Twitter works, so I can't know where, what I'm about to explain, > fails. > > Using the new version (testing), if I'm at the TwitteReader interface > reading and I click to delete a status (that I own), it follows the > process I described above and returns a XML with the last 20 > friend_timeline status where the one I just asked for deletion, should > be gone. Thing is, most of the times, it happens to still be in the > requested XML. After some more tests, I repeated the whole test but > right after deleting the status message, I went to my twiiter.com/home > (logged) with the same account and it wasn't there (the requested > deleted status) and on TwittReader, the friends_timeline requested > (XML) after deletion request, returns with that status (already > deleted on twitter.com) visible. Only some time after, can't be > precise but between 30 to 60 seconds (I think), the request of the XML > (requested by a reload only), will be updated. > > I understand that it automatically disappears from the twitter.com/ > home page as it accesses the DB directly and TwitteReader accesses it > via API. > What I want to know is if the API request via XML or other, sends > cached versions so I can guarantee that it ain't my app design problem > and can fix that "problem" on the client-side (doesn't displaying the > request for deletion status message). > > As the destroy example, the update process, some times, suffers the > same inconsistency when requesting the latest 20 messages after it. > > Long talk but I hope you understand it and also understand my English > coming from a Portuguese. > > Thank you, > mwm. > -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
