You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@esme.apache.org by Vassil Dichev <vd...@apache.org> on 2009/02/14 17:38:40 UTC

Twitter RESTful API

Hello everyone,

There's now partial Twitter RESTful API support for ESME in trunk.
Here's what should work at this point:

- user_timeline
- friends_timeline
- public_timeline
- replies: currently same as user_timeline, might redo it to show conversations
- direct_messages: always empty, because we don't have these in ESME
- verify_credentials: necessary for some Twitter clients

All of the methods should automatically support both XML and JSON.
HTTP Basic authentication is used. The URL prefix used for the API is
"twitter" (it might make sense to make this configurable later on).

So, how do we test this? I've tried with two Twitter clients- one
which uses JSON and one which relies on XML. Here's a short
description:

1. TwitterFox is a lightweight client implemented as a Firefox
extension and uses JSON.
Configuration: find your Firefox profile directory, go to
extensions/twitternotifier@naan.net/components/ and open
nsTwitterNotifier.js for editing. Find the line starting with "const
TWITTER_API_URL" and change the value "https://twitter.com/" to point
to your ESME host and port, e.g. "http://localhost:8080/twitter/".
Make sure ESME is started, (re)start Firefox.

2. Twhirl is an Adobe AIR client, which uses XML for communicating with Twitter.
Unfortunately I didn't find an easy way to reconfigure where twhirl
should connect (and didn't even try much). To work around the problem
here, two things are necessary:
-modifying the /etc/hosts file to change what twitter.com resolves to
-using an Apache instance with URL rewriting is the second necessary
part in deceiving twhirl to think it's connecting to twitter.com. I
won't go into details how to do this, since there's the exhaustive
Apache URL Rewriting guide:

http://httpd.apache.org/docs/2.0/misc/rewriteguide.html

Testing twhirl isn't as easy as I'd hoped, I'm open for suggestions
how I can improve it.

Where to next? I'm not an UI guy and I'll be happy if people could
test as many clients as possible and provide feedback and
instructions. I'll gladly help if there are problems.

What are the plans for extending the API? There are still at least as
many API calls we can easily implement:

- update: this is definitely the first one which must be implemented
next- sending a message completes the communication loop
- getting information: show user info or single message, show friends/followers
- adding and removing friends
- updating a profile

Of course, some refactoring is also necessary since there are some
things which could be implemented in a more elegant way.

That's all, sorry for making you wait this long for this feature.
Don't forget, I'm waiting for your comments!

Have fun,
Vassil

RE: Twitter RESTful API

Posted by "Hirsch, Richard" <ri...@siemens.com>.

Sounds great.
 
I'll try and get the new version of ESME with the Twitter API up on Stax so that everyone can try it soon.
 
If you want to look at another twitter client "Twitterrific " which just runs on Apple. Here is the description how to test this intearction taken from the Present.ly blog (https://www.presentlyapp.com/blog)
 

*	Browse to the Twitterrific application in your Applications folder and Ctrl+Click it, selecting "Show Package Contents" 
*	Open the Contents and Resources directories, then open up the defaults.plist file. 
*	Modify the baseUrl property to be yoursubdomain.presentlyapp.com/api/twitter 
*	Modify the protocol property to be https:// instead of http:// 
*	Save the file and launch Twitterrific 
*	Login using your Present.ly credentials 
*	Voila! 

I'd try it but I just have PCs available.
 
D. 

________________________________

From: vdichev@gmail.com on behalf of Vassil Dichev
Sent: Sat 2/14/2009 17:38
To: esme-dev@incubator.apache.org
Subject: Twitter RESTful API



Hello everyone,

There's now partial Twitter RESTful API support for ESME in trunk.
Here's what should work at this point:

- user_timeline
- friends_timeline
- public_timeline
- replies: currently same as user_timeline, might redo it to show conversations
- direct_messages: always empty, because we don't have these in ESME
- verify_credentials: necessary for some Twitter clients

All of the methods should automatically support both XML and JSON.
HTTP Basic authentication is used. The URL prefix used for the API is
"twitter" (it might make sense to make this configurable later on).

So, how do we test this? I've tried with two Twitter clients- one
which uses JSON and one which relies on XML. Here's a short
description:

1. TwitterFox is a lightweight client implemented as a Firefox
extension and uses JSON.
Configuration: find your Firefox profile directory, go to
extensions/twitternotifier@naan.net/components/ and open
nsTwitterNotifier.js for editing. Find the line starting with "const
TWITTER_API_URL" and change the value "https://twitter.com/" to point
to your ESME host and port, e.g. "http://localhost:8080/twitter/".
Make sure ESME is started, (re)start Firefox.

2. Twhirl is an Adobe AIR client, which uses XML for communicating with Twitter.
Unfortunately I didn't find an easy way to reconfigure where twhirl
should connect (and didn't even try much). To work around the problem
here, two things are necessary:
-modifying the /etc/hosts file to change what twitter.com resolves to
-using an Apache instance with URL rewriting is the second necessary
part in deceiving twhirl to think it's connecting to twitter.com. I
won't go into details how to do this, since there's the exhaustive
Apache URL Rewriting guide:

http://httpd.apache.org/docs/2.0/misc/rewriteguide.html

Testing twhirl isn't as easy as I'd hoped, I'm open for suggestions
how I can improve it.

Where to next? I'm not an UI guy and I'll be happy if people could
test as many clients as possible and provide feedback and
instructions. I'll gladly help if there are problems.

What are the plans for extending the API? There are still at least as
many API calls we can easily implement:

- update: this is definitely the first one which must be implemented
next- sending a message completes the communication loop
- getting information: show user info or single message, show friends/followers
- adding and removing friends
- updating a profile

Of course, some refactoring is also necessary since there are some
things which could be implemented in a more elegant way.

That's all, sorry for making you wait this long for this feature.
Don't forget, I'm waiting for your comments!

Have fun,
Vassil

AW: Problem with ESME Resource File name

Posted by "Hirsch, Richard" <ri...@siemens.com>.

Great. Thanks. I'll try it out.

D.  

-----Ursprüngliche Nachricht-----
Von: vdichev@gmail.com [mailto:vdichev@gmail.com] Im Auftrag von Vassil Dichev
Gesendet: Montag, 23. Februar 2009 09:15
An: esme-dev@incubator.apache.org
Betreff: Re: Problem with ESME Resource File name

> Right now, we are using a property file that is based on the System.user
> property. This is fine when this user is known in advance. In many
> settings (including Stax), this knowledge is not available. I've created
> a Jira issue with a new suggestion:
> http://issues.apache.org/jira/browse/ESME-41

This is a Lift feature:
http://liftweb.net/index.php/Cheat_Sheet#Property_files
You can also use the host name, or if that's also not known (as is
likely on a stax deployment), just use default.props

Re: Problem with ESME Resource File name

Posted by Vassil Dichev <vd...@apache.org>.

> Right now, we are using a property file that is based on the System.user
> property. This is fine when this user is known in advance. In many
> settings (including Stax), this knowledge is not available. I've created
> a Jira issue with a new suggestion:
> http://issues.apache.org/jira/browse/ESME-41

This is a Lift feature:
http://liftweb.net/index.php/Cheat_Sheet#Property_files
You can also use the host name, or if that's also not known (as is
likely on a stax deployment), just use default.props

Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

Posted by Anne Kathrine Petteroe <yo...@gmail.com>.

Do you mean ideas for other apps we can try?

/Anne


On 25. feb.. 2009, at 21.13, Hirsch, Richard wrote:

> You may want to look here for some other ideas: http://laconi.ca/trac/wiki/Apps
>
> D.
>
> ________________________________
>
> From: Anne Kathrine Petteroe [mailto:yojibee@gmail.com]
> Sent: Wed 25.02.2009 21:01
> To: esme-dev@incubator.apache.org
> Subject: Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working  
> with ESME
>
>
>
> I have created an App page in our wiki.
> I decided to focus on the apps which work, not sure if we tried any
> which didn't work?
>
> http://cwiki.apache.org/confluence/display/ESME/Apps
>
> /Anne
>
> On 23. feb.. 2009, at 11.40, Oliver Kohl wrote:
>
>> I would like to add Twitterrific to the list. I have tested it and
>> can write
>> up a blog post on how to change the configuration and about the
>> gotchas.
>>
>> Cheers,
>> Oliver
>>
>> On Mon, Feb 23, 2009 at 08:54, Hirsch, Richard
>> <ri...@siemens.com>wrote:
>>
>>> Good idea. I'd add links to the various blogs for more details:
>>>
>>> Initial List
>>> * Twhirl (AIR)
>>> * LaTwit (Iphone)
>>> * Ping.fm
>>>
>>> Etc.
>>>
>>> D.
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: vdichev@gmail.com [mailto:vdichev@gmail.com] Im Auftrag von
>>> Vassil
>>> Dichev
>>> Gesendet: Montag, 23. Februar 2009 08:46
>>> An: esme-dev@incubator.apache.org
>>> Betreff: Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working
>>> with
>>> ESME
>>>
>>>> Thank you for doing this, Vassil!
>>>> I cannot begin to tell you how awesome it is to follow the ESME
>>> conversation
>>>> on my iPhone.
>>>> It even works better than on the web UI, because I can see
>>>> everyone's
>>>> avatars :-)
>>>
>>> Thanks to all of you for testing and spreading the word!
>>>
>>> Maybe we should have a wiki page with clients that are tested to  
>>> work
>>> and ones which have problems.
>>>
>
>
>

RE: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

Posted by "Hirsch, Richard" <ri...@siemens.com>.

You may want to look here for some other ideas: http://laconi.ca/trac/wiki/Apps
 
D. 

________________________________

From: Anne Kathrine Petteroe [mailto:yojibee@gmail.com]
Sent: Wed 25.02.2009 21:01
To: esme-dev@incubator.apache.org
Subject: Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME



I have created an App page in our wiki.
I decided to focus on the apps which work, not sure if we tried any 
which didn't work?

http://cwiki.apache.org/confluence/display/ESME/Apps

/Anne

On 23. feb.. 2009, at 11.40, Oliver Kohl wrote:

> I would like to add Twitterrific to the list. I have tested it and 
> can write
> up a blog post on how to change the configuration and about the 
> gotchas.
>
> Cheers,
>  Oliver
>
> On Mon, Feb 23, 2009 at 08:54, Hirsch, Richard
> <ri...@siemens.com>wrote:
>
>> Good idea. I'd add links to the various blogs for more details:
>>
>> Initial List
>> * Twhirl (AIR)
>> * LaTwit (Iphone)
>> * Ping.fm
>>
>> Etc.
>>
>> D.
>>
>> -----Ursprüngliche Nachricht-----
>> Von: vdichev@gmail.com [mailto:vdichev@gmail.com] Im Auftrag von 
>> Vassil
>> Dichev
>> Gesendet: Montag, 23. Februar 2009 08:46
>> An: esme-dev@incubator.apache.org
>> Betreff: Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working 
>> with
>> ESME
>>
>>> Thank you for doing this, Vassil!
>>> I cannot begin to tell you how awesome it is to follow the ESME
>> conversation
>>> on my iPhone.
>>> It even works better than on the web UI, because I can see 
>>> everyone's
>>> avatars :-)
>>
>> Thanks to all of you for testing and spreading the word!
>>
>> Maybe we should have a wiki page with clients that are tested to work
>> and ones which have problems.
>>

Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

Posted by Anne Kathrine Petteroe <yo...@gmail.com>.

I have created an App page in our wiki.
I decided to focus on the apps which work, not sure if we tried any  
which didn't work?

http://cwiki.apache.org/confluence/display/ESME/Apps

/Anne

On 23. feb.. 2009, at 11.40, Oliver Kohl wrote:

> I would like to add Twitterrific to the list. I have tested it and  
> can write
> up a blog post on how to change the configuration and about the  
> gotchas.
>
> Cheers,
>  Oliver
>
> On Mon, Feb 23, 2009 at 08:54, Hirsch, Richard
> <ri...@siemens.com>wrote:
>
>> Good idea. I'd add links to the various blogs for more details:
>>
>> Initial List
>> * Twhirl (AIR)
>> * LaTwit (Iphone)
>> * Ping.fm
>>
>> Etc.
>>
>> D.
>>
>> -----Ursprüngliche Nachricht-----
>> Von: vdichev@gmail.com [mailto:vdichev@gmail.com] Im Auftrag von  
>> Vassil
>> Dichev
>> Gesendet: Montag, 23. Februar 2009 08:46
>> An: esme-dev@incubator.apache.org
>> Betreff: Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working  
>> with
>> ESME
>>
>>> Thank you for doing this, Vassil!
>>> I cannot begin to tell you how awesome it is to follow the ESME
>> conversation
>>> on my iPhone.
>>> It even works better than on the web UI, because I can see  
>>> everyone's
>>> avatars :-)
>>
>> Thanks to all of you for testing and spreading the word!
>>
>> Maybe we should have a wiki page with clients that are tested to work
>> and ones which have problems.
>>

AW: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

Posted by "Hirsch, Richard" <ri...@siemens.com>.

@Oliver: That would be great. Thanks.

D.  

-----Ursprüngliche Nachricht-----
Von: Oliver Kohl [mailto:zsapping@googlemail.com] 
Gesendet: Montag, 23. Februar 2009 11:40
An: esme-dev@incubator.apache.org
Betreff: Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

I would like to add Twitterrific to the list. I have tested it and can write
up a blog post on how to change the configuration and about the gotchas.

Cheers,
  Oliver

On Mon, Feb 23, 2009 at 08:54, Hirsch, Richard
<ri...@siemens.com>wrote:

> Good idea. I'd add links to the various blogs for more details:
>
> Initial List
> * Twhirl (AIR)
> * LaTwit (Iphone)
> * Ping.fm
>
> Etc.
>
> D.
>
> -----Ursprüngliche Nachricht-----
> Von: vdichev@gmail.com [mailto:vdichev@gmail.com] Im Auftrag von Vassil
> Dichev
> Gesendet: Montag, 23. Februar 2009 08:46
> An: esme-dev@incubator.apache.org
> Betreff: Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with
> ESME
>
> > Thank you for doing this, Vassil!
> > I cannot begin to tell you how awesome it is to follow the ESME
> conversation
> > on my iPhone.
> > It even works better than on the web UI, because I can see everyone's
> > avatars :-)
>
> Thanks to all of you for testing and spreading the word!
>
> Maybe we should have a wiki page with clients that are tested to work
> and ones which have problems.
>

Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

Posted by Oliver Kohl <zs...@googlemail.com>.

I would like to add Twitterrific to the list. I have tested it and can write
up a blog post on how to change the configuration and about the gotchas.

Cheers,
  Oliver

On Mon, Feb 23, 2009 at 08:54, Hirsch, Richard
<ri...@siemens.com>wrote:

> Good idea. I'd add links to the various blogs for more details:
>
> Initial List
> * Twhirl (AIR)
> * LaTwit (Iphone)
> * Ping.fm
>
> Etc.
>
> D.
>
> -----Ursprüngliche Nachricht-----
> Von: vdichev@gmail.com [mailto:vdichev@gmail.com] Im Auftrag von Vassil
> Dichev
> Gesendet: Montag, 23. Februar 2009 08:46
> An: esme-dev@incubator.apache.org
> Betreff: Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with
> ESME
>
> > Thank you for doing this, Vassil!
> > I cannot begin to tell you how awesome it is to follow the ESME
> conversation
> > on my iPhone.
> > It even works better than on the web UI, because I can see everyone's
> > avatars :-)
>
> Thanks to all of you for testing and spreading the word!
>
> Maybe we should have a wiki page with clients that are tested to work
> and ones which have problems.
>

Problem with ESME Resource File name

Posted by "Hirsch, Richard" <ri...@siemens.com>.

Right now, we are using a property file that is based on the System.user
property. This is fine when this user is known in advance. In many
settings (including Stax), this knowledge is not available. I've created
a Jira issue with a new suggestion:
http://issues.apache.org/jira/browse/ESME-41

D.

Re: AW: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

Posted by Anne Kathrine Petteroe <yo...@gmail.com>.

I don't have editing access to our wiki yet (forgot to request it), so  
I cannot add it.
If no one else have done it before I get the access, I will create the  
page then.

/Anne


On 23. feb.. 2009, at 08.54, Hirsch, Richard wrote:

> Good idea. I'd add links to the various blogs for more details:
>
> Initial List
> * Twhirl (AIR)
> * LaTwit (Iphone)
> * Ping.fm
>
> Etc.
>
> D.
>
> -----Ursprüngliche Nachricht-----
> Von: vdichev@gmail.com [mailto:vdichev@gmail.com] Im Auftrag von  
> Vassil Dichev
> Gesendet: Montag, 23. Februar 2009 08:46
> An: esme-dev@incubator.apache.org
> Betreff: Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working  
> with ESME
>
>> Thank you for doing this, Vassil!
>> I cannot begin to tell you how awesome it is to follow the ESME  
>> conversation
>> on my iPhone.
>> It even works better than on the web UI, because I can see everyone's
>> avatars :-)
>
> Thanks to all of you for testing and spreading the word!
>
> Maybe we should have a wiki page with clients that are tested to work
> and ones which have problems.

AW: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

Posted by "Hirsch, Richard" <ri...@siemens.com>.

Good idea. I'd add links to the various blogs for more details:

Initial List 
* Twhirl (AIR)
* LaTwit (Iphone)
* Ping.fm

Etc.

D. 

-----Ursprüngliche Nachricht-----
Von: vdichev@gmail.com [mailto:vdichev@gmail.com] Im Auftrag von Vassil Dichev
Gesendet: Montag, 23. Februar 2009 08:46
An: esme-dev@incubator.apache.org
Betreff: Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

> Thank you for doing this, Vassil!
> I cannot begin to tell you how awesome it is to follow the ESME conversation
> on my iPhone.
> It even works better than on the web UI, because I can see everyone's
> avatars :-)

Thanks to all of you for testing and spreading the word!

Maybe we should have a wiki page with clients that are tested to work
and ones which have problems.

Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

Posted by Vassil Dichev <vd...@apache.org>.

> Thank you for doing this, Vassil!
> I cannot begin to tell you how awesome it is to follow the ESME conversation
> on my iPhone.
> It even works better than on the web UI, because I can see everyone's
> avatars :-)

Thanks to all of you for testing and spreading the word!

Maybe we should have a wiki page with clients that are tested to work
and ones which have problems.

Re: Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

Posted by Anne Kathrine Petteroe <yo...@gmail.com>.

Thank you for doing this, Vassil!
I cannot begin to tell you how awesome it is to follow the ESME  
conversation on my iPhone.
It even works better than on the web UI, because I can see everyone's  
avatars :-)

/Anne

On 22. feb.. 2009, at 19.02, Hirsch, Richard wrote:

> Don't know whether people have been watching the twitter traffic /  
> ESME blog or not.
>
> Just wanted to let the list know that we now have a variety of new  
> clients accessing ESME now. We are using clients that call laconi.ca  
> systems and redirecting them to ESME.
>
> Very cool. Thanks to Vassil (and other extended team members for  
> acting as guinea pigs / testers) for moving us forward.
>
> D.
>

Twitter Clients (AIR, iPhone, ping.fm, etc.) working with ESME

Posted by "Hirsch, Richard" <ri...@siemens.com>.

Don't know whether people have been watching the twitter traffic / ESME blog or not.

Just wanted to let the list know that we now have a variety of new clients accessing ESME now. We are using clients that call laconi.ca systems and redirecting them to ESME. 

Very cool. Thanks to Vassil (and other extended team members for acting as guinea pigs / testers) for moving us forward. 

D.

Re: Twitter RESTful API

Posted by Darren Hague <dh...@fortybeans.com>.

Awesome work - well done, Vassil.

- Darren

Vassil Dichev wrote:
> Friends / followers can now also be fetched from the Twitter API,
> though I don't know many Twitter clients which make use of this.
>
> I've also done some refactoring of the code. You can now also specify
> an URL prefix for the Twitter API with multiple segments, like this:
> "twitter/api". This should help avoid conflicts with our own ESME API.
>

RE: Twitter RESTful API

Posted by "Hirsch, Richard" <ri...@siemens.com>.

very cool. I'll do a stax deployment today. 
 
BTW: Expect an esme blog about twitter api today as well.
 
D. 
 

________________________________

From: vdichev@gmail.com on behalf of Vassil Dichev
Sent: Fri 2/20/2009 23:57
To: esme-dev@incubator.apache.org
Subject: Re: Twitter RESTful API



Friends / followers can now also be fetched from the Twitter API,
though I don't know many Twitter clients which make use of this.

I've also done some refactoring of the code. You can now also specify
an URL prefix for the Twitter API with multiple segments, like this:
"twitter/api". This should help avoid conflicts with our own ESME API.

Re: Twitter RESTful API

Posted by Vassil Dichev <vd...@apache.org>.

Friends / followers can now also be fetched from the Twitter API,
though I don't know many Twitter clients which make use of this.

I've also done some refactoring of the code. You can now also specify
an URL prefix for the Twitter API with multiple segments, like this:
"twitter/api". This should help avoid conflicts with our own ESME API.

Re: Twitter RESTful API

Posted by Vassil Dichev <vd...@apache.org>.

> This is definitely undesirable behavior, so it won't stay like this for long.

Missing / duplicate messages bug fixed.

SMS with ESME: action

Posted by "Hirsch, Richard" <ri...@siemens.com>.

Just found this interesting blog about texting with lift / scala :
http://scala-blogs.org/2008/06/emailing-and-texting-with-scala-lift.html

Would be perfect as an action. 

D.

Re: Twitter RESTful API

Posted by Vassil Dichev <vd...@apache.org>.

> Just tried again. The first message sent appears in twhirl after that no other messages appear in thwirl. The messages, however, do appear in the web UI.

> Sorry. It did work. There was a delay concerning the receipt of the messages.

Both of your observations are correct, and coincide with my
experience. When the message is posted, twhirl updates the timeline
with the response from the Twitter API. All the messages returned,
though, have an id of -1, so only the first is shown, all the next
ones are identified as duplicated ones, judging from their ids. When
twhirl does a full update by requesting the list of last messages in
the timeline, these arrive with correct unique ids, so the timeline is
updated. You'll notice, though, that the first posted message is
duplicated twice- once with the -1 id, and a second time with the
correct generated id.

This is definitely undesirable behavior, so it won't stay like this for long.

AW: Twitter RESTful API

Posted by "Hirsch, Richard" <ri...@siemens.com>.

Sorry. It did work. There was a delay concerning the receipt of the messages.

D.  

-----Ursprüngliche Nachricht-----
Von: Hirsch, Richard 
Gesendet: Mittwoch, 18. Februar 2009 09:19
An: esme-dev@incubator.apache.org
Betreff: AW: Twitter RESTful API

Just tried again. The first message sent appears in twhirl after that no other messages appear in thwirl. The messages, however, do appear in the web UI. 

D. 

-----Ursprüngliche Nachricht-----
Von: Hirsch, Richard 
Gesendet: Mittwoch, 18. Februar 2009 09:17
An: esme-dev@incubator.apache.org
Betreff: AW: Twitter RESTful API

It works from twhirl!

Good job

D. 

-----Ursprüngliche Nachricht-----
Von: vdichev@gmail.com [mailto:vdichev@gmail.com] Im Auftrag von Vassil Dichev
Gesendet: Mittwoch, 18. Februar 2009 07:04
An: esme-dev@incubator.apache.org
Betreff: Re: Twitter RESTful API

Posting status updates now works, with a small caveat- the message is
sent asynchronously, so the API doesn't wait for the answer which id
the created message has. As a result clients might have problems
displaying new messages posted from their own interface- it's possible
that some messages seemingly disappear and some seem to be posted
twice. Check web interface to ascertain that all is OK.

I'll see how I can best fix this problem.

AW: Twitter RESTful API

Posted by "Hirsch, Richard" <ri...@siemens.com>.

Just tried again. The first message sent appears in twhirl after that no other messages appear in thwirl. The messages, however, do appear in the web UI. 

D. 

-----Ursprüngliche Nachricht-----
Von: Hirsch, Richard 
Gesendet: Mittwoch, 18. Februar 2009 09:17
An: esme-dev@incubator.apache.org
Betreff: AW: Twitter RESTful API

It works from twhirl!

Good job

D. 

-----Ursprüngliche Nachricht-----
Von: vdichev@gmail.com [mailto:vdichev@gmail.com] Im Auftrag von Vassil Dichev
Gesendet: Mittwoch, 18. Februar 2009 07:04
An: esme-dev@incubator.apache.org
Betreff: Re: Twitter RESTful API

Posting status updates now works, with a small caveat- the message is
sent asynchronously, so the API doesn't wait for the answer which id
the created message has. As a result clients might have problems
displaying new messages posted from their own interface- it's possible
that some messages seemingly disappear and some seem to be posted
twice. Check web interface to ascertain that all is OK.

I'll see how I can best fix this problem.

AW: Twitter RESTful API

Posted by "Hirsch, Richard" <ri...@siemens.com>.

It works from twhirl!

Good job

D. 

-----Ursprüngliche Nachricht-----
Von: vdichev@gmail.com [mailto:vdichev@gmail.com] Im Auftrag von Vassil Dichev
Gesendet: Mittwoch, 18. Februar 2009 07:04
An: esme-dev@incubator.apache.org
Betreff: Re: Twitter RESTful API

Posting status updates now works, with a small caveat- the message is
sent asynchronously, so the API doesn't wait for the answer which id
the created message has. As a result clients might have problems
displaying new messages posted from their own interface- it's possible
that some messages seemingly disappear and some seem to be posted
twice. Check web interface to ascertain that all is OK.

I'll see how I can best fix this problem.

Re: Twitter RESTful API

Posted by Vassil Dichev <vd...@apache.org>.

Posting status updates now works, with a small caveat- the message is
sent asynchronously, so the API doesn't wait for the answer which id
the created message has. As a result clients might have problems
displaying new messages posted from their own interface- it's possible
that some messages seemingly disappear and some seem to be posted
twice. Check web interface to ascertain that all is OK.

I'll see how I can best fix this problem.

AW: Twitter RESTful API

Posted by "Hirsch, Richard" <ri...@siemens.com>.

 There is already a description (in the Google Code) from Mrinal on how to do this
D. 
-----Ursprüngliche Nachricht-----
Von: Vassil Dichev [mailto:vdichev@gmail.com] 
Gesendet: Montag, 16. Februar 2009 08:41
An: esme-dev@incubator.apache.org
Betreff: Re: Twitter RESTful API

> Re Problem with "api" - that means if we switch to "api" for twitter api access then we will have conflicts with our those existing clients using own rest api.  What about making the ESME REST API Url configurable -  just like you did for the twitter api URL.  It defaults to "api" but you can change it if you want. Then you get set it to "esme_api" to distinguish the two. This would also provide more flexibility.

Good idea, it crossed my mind actually, but then we have to also make
sure our own ESME desktop clients are configurable as well.

Re: Twitter RESTful API

Posted by Vassil Dichev <vd...@gmail.com>.

> Re Problem with "api" - that means if we switch to "api" for twitter api access then we will have conflicts with our those existing clients using own rest api.  What about making the ESME REST API Url configurable -  just like you did for the twitter api URL.  It defaults to "api" but you can change it if you want. Then you get set it to "esme_api" to distinguish the two. This would also provide more flexibility.

Good idea, it crossed my mind actually, but then we have to also make
sure our own ESME desktop clients are configurable as well.

AW: Twitter RESTful API

Posted by "Hirsch, Richard" <ri...@siemens.com>.

OK. Thanks for filling me in.

Re Problem with "api" - that means if we switch to "api" for twitter api access then we will have conflicts with our those existing clients using own rest api. What about making the ESME REST API Url configurable - just like you did for the twitter api URL. It defaults to "api" but you can change it if you want. Then you get set it to "esme_api" to distinguish the two. This would also provide more flexibility.

________________________________

Von: vdichev@gmail.com im Auftrag von Vassil Dichev
Gesendet: Mo 2/16/2009 08:28
An: esme-dev@incubator.apache.org
Betreff: Re: Twitter RESTful API

> From what I saw, it is not ""twitter/api" but "twitter" (JSON) or "api" (XML). Probably have to check the twitter api again to make sure. That means we don't need a url with two segments but two separate URLs.

The Twitter API documentation
(http://apiwiki.twitter.com/REST+API+Documentation) doesn't use any
particular prefix, and json and xml calls are distinguished by the
suffix- e.g. friends_timeline.json vs. friends_timeline.xml. Laconi.ca
uses the "api" prefix for their twitter REST API, probably to prevent
clashes with their own URLs.

The problem with ESME is that it uses "api" already for its own
RESTful API, so by default the Twitter API prefix is "twitter". Some
clients' configuration is not very flexible (twhirl, which was used
for testing our API) so it requires the "api" prefix. You could
configure ESME to use "api" as a prefix, but this would lead to some
undesirable consequences, e.g. our own API would require HTTP Basic
authentication as well, which would probably confuse our own ESME
desktop clients.

The problem could be solved if we use a prefix, consisting of multiple
segments, e.g. "twitter/api", I'm currently working on ways to
integrate it with our twitter API. Again: whether to serve XML or JSON
doesn't depend on the prefix, but the suffix.

Re: Twitter RESTful API

Posted by Vassil Dichev <vd...@apache.org>.

> From what I saw, it is not ""twitter/api" but "twitter" (JSON) or "api" (XML). Probably have to check the twitter api again to make sure.  That means we don't need a url with two segments but two separate URLs.

The Twitter API documentation
(http://apiwiki.twitter.com/REST+API+Documentation) doesn't use any
particular prefix, and json and xml calls are distinguished by the
suffix- e.g. friends_timeline.json vs. friends_timeline.xml. Laconi.ca
uses the "api" prefix for their twitter REST API, probably to prevent
clashes with their own URLs.

The problem with ESME is that it uses "api" already for its own
RESTful API, so by default the Twitter API prefix is "twitter". Some
clients' configuration is not very flexible (twhirl, which was used
for testing our API) so it requires the "api" prefix. You could
configure ESME to use "api" as a prefix, but this would lead to some
undesirable consequences, e.g. our own API would require HTTP Basic
authentication as well, which would probably confuse our own ESME
desktop clients.

The problem could be solved if we use a prefix, consisting of multiple
segments, e.g. "twitter/api", I'm currently working on ways to
integrate it with our twitter API. Again: whether to serve XML or JSON
doesn't depend on the prefix, but the suffix.

RE: Twitter RESTful API

Posted by "Hirsch, Richard" <ri...@siemens.com>.

>From what I saw, it is not ""twitter/api" but "twitter" (JSON) or "api" (XML). Probably have to check the twitter api again to make sure.  That means we don't need a url with two segments but two separate URLs.
 
D. 

________________________________

From: Vassil Dichev [mailto:vdichev@gmail.com]
Sent: Sun 2/15/2009 23:27
To: esme-dev@incubator.apache.org
Subject: Re: Twitter RESTful API



> Just tried twhirl based on this blog from shoutem (http://blog.shoutem.com/2009/02/14/how-to-setup-shoutem-desktop-app-twhirl/). Example: Use this as your user: apachedick@esmecloudserverapache.dickhirsch.staxapps.net/twitter
>
> Here are the results from the call - all 404s. I don't know whether the problem is the "api" in the URL

Ah, right, Twhirl works with laconi.ca, which has a twitter-compatible API.

I've committed configuration via properties- you should now be able to
connect with twhirl if you configure
twitter.prefix=api

Unfortunately, I still don't see an easy way to configure a URL with
several segments, like "twitter/api".

Then there's the problem that Twhirl still tries to connect through
SSL only, so you need to configure Jetty for SSL or at least use some
sort of SSL proxy/tunnel.

Re: Twitter RESTful API

Posted by Vassil Dichev <vd...@gmail.com>.

> Just tried twhirl based on this blog from shoutem (http://blog.shoutem.com/2009/02/14/how-to-setup-shoutem-desktop-app-twhirl/). Example: Use this as your user: apachedick@esmecloudserverapache.dickhirsch.staxapps.net/twitter
>
> Here are the results from the call - all 404s. I don't know whether the problem is the "api" in the URL

Ah, right, Twhirl works with laconi.ca, which has a twitter-compatible API.

I've committed configuration via properties- you should now be able to
connect with twhirl if you configure
twitter.prefix=api

Unfortunately, I still don't see an easy way to configure a URL with
several segments, like "twitter/api".

Then there's the problem that Twhirl still tries to connect through
SSL only, so you need to configure Jetty for SSL or at least use some
sort of SSL proxy/tunnel.

Re: AW: Twitter RESTful API

Posted by Anne Kathrine Petteroe <yo...@gmail.com>.

Hi,

I have successfully connected with TwitterFox.
I wanted to try it with Twitterrific tonight, but ran into some  
unforeseen issues with Parallels Desktop and VPN which I needed to  
take care of.
Will try it out tomorrow evening - or if I get a moment at work during  
the day, it is difficult to wait.

/Anne

On 14. feb.. 2009, at 23.48, Hirsch, Richard wrote:

> Just tried http://esmecloudserverapache.dickhirsch.staxapps.net/twitter/statuses/public_timeline.xml 
>  it works. Twhirl is however asking for /twitter/api/statuses/ 
> public_timeline.xml. "API" is missing.
>
> If you add api to the url, twhirl will work as well. #
>
> D.
>
> ________________________________
>
> Von: Hirsch, Richard
> Gesendet: Sa 2/14/2009 23:41
> An: esme-dev@incubator.apache.org
> Betreff: AW: Twitter RESTful API
>
>
>
> Just tried twhirl based on this blog from shoutem (http://blog.shoutem.com/2009/02/14/how-to-setup-shoutem-desktop-app-twhirl/ 
> ). Example: Use this as your user: apachedick@esmecloudserverapache.dickhirsch.staxapps.net 
> /twitter
>
> Here are the results from the call - all 404s. I don't know whether  
> the problem is the "api" in the URL
>
> 62.47.189.9 - apachedick [14/Feb/2009:22:39:06 +0000] "GET /twitter/ 
> api/account/verify_credentials.xml? HTTP/1.1" 404 1081 "app:/ 
> twhirl.swf" "twhirl/0.9 (Windows; U; Windows XP; de) AdobeAIR/ 
> 1.5.0.7220"
> 62.47.189.9 - apachedick [14/Feb/2009:22:39:07 +0000] "GET /twitter/ 
> api/statuses/friends_timeline.xml?count=20 HTTP/1.1" 404 1078 "app:/ 
> twhirl.swf" "twhirl/0.9 (Windows; U; Windows XP; de) AdobeAIR/ 
> 1.5.0.7220"
> 62.47.189.9 - apachedick [14/Feb/2009:22:39:08 +0000] "GET /twitter/ 
> api/statuses/replies.xml? HTTP/1.1" 404 1051 "app:/twhirl.swf"  
> "twhirl/0.9 (Windows; U; Windows XP; de) AdobeAIR/1.5.0.7220"
> 62.47.189.9 - apachedick [14/Feb/2009:22:39:09 +0000] "GET /twitter/ 
> api/direct_messages.xml? HTTP/1.1" 404 1048 "app:/twhirl.swf"  
> "twhirl/0.9 (Windows; U; Windows XP; de) AdobeAIR/1.5.0.7220"
> 62.47.189.9 - apachedick [14/Feb/2009:22:39:10 +0000] "GET /twitter/ 
> api/statuses/public_timeline.xml? HTTP/1.1" 404 1075 "app:/ 
> twhirl.swf" "twhirl/0.9 (Windows; U; Windows XP; de) AdobeAIR/ 
> 1.5.0.7220"
> D.
>
> ________________________________
>
> Von: vdichev@gmail.com im Auftrag von Vassil Dichev
> Gesendet: Sa 2/14/2009 17:38
> An: esme-dev@incubator.apache.org
> Betreff: Twitter RESTful API
>
>
>
> Hello everyone,
>
> There's now partial Twitter RESTful API support for ESME in trunk.
> Here's what should work at this point:
>
> - user_timeline
> - friends_timeline
> - public_timeline
> - replies: currently same as user_timeline, might redo it to show  
> conversations
> - direct_messages: always empty, because we don't have these in ESME
> - verify_credentials: necessary for some Twitter clients
>
> All of the methods should automatically support both XML and JSON.
> HTTP Basic authentication is used. The URL prefix used for the API is
> "twitter" (it might make sense to make this configurable later on).
>
> So, how do we test this? I've tried with two Twitter clients- one
> which uses JSON and one which relies on XML. Here's a short
> description:
>
> 1. TwitterFox is a lightweight client implemented as a Firefox
> extension and uses JSON.
> Configuration: find your Firefox profile directory, go to
> extensions/twitternotifier@naan.net/components/ and open
> nsTwitterNotifier.js for editing. Find the line starting with "const
> TWITTER_API_URL" and change the value "https://twitter.com/" to point
> to your ESME host and port, e.g. "http://localhost:8080/twitter/".
> Make sure ESME is started, (re)start Firefox.
>
> 2. Twhirl is an Adobe AIR client, which uses XML for communicating  
> with Twitter.
> Unfortunately I didn't find an easy way to reconfigure where twhirl
> should connect (and didn't even try much). To work around the problem
> here, two things are necessary:
> -modifying the /etc/hosts file to change what twitter.com resolves to
> -using an Apache instance with URL rewriting is the second necessary
> part in deceiving twhirl to think it's connecting to twitter.com. I
> won't go into details how to do this, since there's the exhaustive
> Apache URL Rewriting guide:
>
> http://httpd.apache.org/docs/2.0/misc/rewriteguide.html
>
> Testing twhirl isn't as easy as I'd hoped, I'm open for suggestions
> how I can improve it.
>
> Where to next? I'm not an UI guy and I'll be happy if people could
> test as many clients as possible and provide feedback and
> instructions. I'll gladly help if there are problems.
>
> What are the plans for extending the API? There are still at least as
> many API calls we can easily implement:
>
> - update: this is definitely the first one which must be implemented
> next- sending a message completes the communication loop
> - getting information: show user info or single message, show  
> friends/followers
> - adding and removing friends
> - updating a profile
>
> Of course, some refactoring is also necessary since there are some
> things which could be implemented in a more elegant way.
>
> That's all, sorry for making you wait this long for this feature.
> Don't forget, I'm waiting for your comments!
>
> Have fun,
> Vassil
>
>
>
>

AW: Twitter RESTful API

Posted by "Hirsch, Richard" <ri...@siemens.com>.

Just tried http://esmecloudserverapache.dickhirsch.staxapps.net/twitter/statuses/public_timeline.xml it works. Twhirl is however asking for /twitter/api/statuses/public_timeline.xml. "API" is missing.

If you add api to the url, twhirl will work as well. #

________________________________

Von: Hirsch, Richard
Gesendet: Sa 2/14/2009 23:41
An: esme-dev@incubator.apache.org
Betreff: AW: Twitter RESTful API

Just tried twhirl based on this blog from shoutem (http://blog.shoutem.com/2009/02/14/how-to-setup-shoutem-desktop-app-twhirl/). Example: Use this as your user: apachedick@esmecloudserverapache.dickhirsch.staxapps.net/twitter

Here are the results from the call - all 404s. I don't know whether the problem is the "api" in the URL

62.47.189.9 - apachedick [14/Feb/2009:22:39:06 +0000] "GET /twitter/api/account/verify_credentials.xml? HTTP/1.1" 404 1081 "app:/twhirl.swf" "twhirl/0.9 (Windows; U; Windows XP; de) AdobeAIR/1.5.0.7220"
62.47.189.9 - apachedick [14/Feb/2009:22:39:07 +0000] "GET /twitter/api/statuses/friends_timeline.xml?count=20 HTTP/1.1" 404 1078 "app:/twhirl.swf" "twhirl/0.9 (Windows; U; Windows XP; de) AdobeAIR/1.5.0.7220"
62.47.189.9 - apachedick [14/Feb/2009:22:39:08 +0000] "GET /twitter/api/statuses/replies.xml? HTTP/1.1" 404 1051 "app:/twhirl.swf" "twhirl/0.9 (Windows; U; Windows XP; de) AdobeAIR/1.5.0.7220"
62.47.189.9 - apachedick [14/Feb/2009:22:39:09 +0000] "GET /twitter/api/direct_messages.xml? HTTP/1.1" 404 1048 "app:/twhirl.swf" "twhirl/0.9 (Windows; U; Windows XP; de) AdobeAIR/1.5.0.7220"
62.47.189.9 - apachedick [14/Feb/2009:22:39:10 +0000] "GET /twitter/api/statuses/public_timeline.xml? HTTP/1.1" 404 1075 "app:/twhirl.swf" "twhirl/0.9 (Windows; U; Windows XP; de) AdobeAIR/1.5.0.7220"
D.

________________________________

Von: vdichev@gmail.com im Auftrag von Vassil Dichev
Gesendet: Sa 2/14/2009 17:38
An: esme-dev@incubator.apache.org
Betreff: Twitter RESTful API

Hello everyone,

There's now partial Twitter RESTful API support for ESME in trunk.
Here's what should work at this point:

- user_timeline
- friends_timeline
- public_timeline
- replies: currently same as user_timeline, might redo it to show conversations
- direct_messages: always empty, because we don't have these in ESME
- verify_credentials: necessary for some Twitter clients

All of the methods should automatically support both XML and JSON.
HTTP Basic authentication is used. The URL prefix used for the API is
"twitter" (it might make sense to make this configurable later on).

So, how do we test this? I've tried with two Twitter clients- one
which uses JSON and one which relies on XML. Here's a short
description:

1. TwitterFox is a lightweight client implemented as a Firefox
extension and uses JSON.
Configuration: find your Firefox profile directory, go to
extensions/twitternotifier@naan.net/components/ and open
nsTwitterNotifier.js for editing. Find the line starting with "const
TWITTER_API_URL" and change the value "https://twitter.com/" to point
to your ESME host and port, e.g. "http://localhost:8080/twitter/".
Make sure ESME is started, (re)start Firefox.

2. Twhirl is an Adobe AIR client, which uses XML for communicating with Twitter.
Unfortunately I didn't find an easy way to reconfigure where twhirl
should connect (and didn't even try much). To work around the problem
here, two things are necessary:
-modifying the /etc/hosts file to change what twitter.com resolves to
-using an Apache instance with URL rewriting is the second necessary
part in deceiving twhirl to think it's connecting to twitter.com. I
won't go into details how to do this, since there's the exhaustive
Apache URL Rewriting guide:

http://httpd.apache.org/docs/2.0/misc/rewriteguide.html

Testing twhirl isn't as easy as I'd hoped, I'm open for suggestions
how I can improve it.

Where to next? I'm not an UI guy and I'll be happy if people could
test as many clients as possible and provide feedback and
instructions. I'll gladly help if there are problems.

What are the plans for extending the API? There are still at least as
many API calls we can easily implement:

- update: this is definitely the first one which must be implemented
next- sending a message completes the communication loop
- getting information: show user info or single message, show friends/followers
- adding and removing friends
- updating a profile

Of course, some refactoring is also necessary since there are some
things which could be implemented in a more elegant way.

That's all, sorry for making you wait this long for this feature.
Don't forget, I'm waiting for your comments!

Have fun,
Vassil

AW: Twitter RESTful API

Posted by "Hirsch, Richard" <ri...@siemens.com>.

Here are the results from the call - all 404s. I don't know whether the problem is the "api" in the URL

________________________________

Von: vdichev@gmail.com im Auftrag von Vassil Dichev
Gesendet: Sa 2/14/2009 17:38
An: esme-dev@incubator.apache.org
Betreff: Twitter RESTful API

Hello everyone,

There's now partial Twitter RESTful API support for ESME in trunk.
Here's what should work at this point:

So, how do we test this? I've tried with two Twitter clients- one
which uses JSON and one which relies on XML. Here's a short
description:

http://httpd.apache.org/docs/2.0/misc/rewriteguide.html

Testing twhirl isn't as easy as I'd hoped, I'm open for suggestions
how I can improve it.

Where to next? I'm not an UI guy and I'll be happy if people could
test as many clients as possible and provide feedback and
instructions. I'll gladly help if there are problems.

What are the plans for extending the API? There are still at least as
many API calls we can easily implement:

Of course, some refactoring is also necessary since there are some
things which could be implemented in a more elegant way.

That's all, sorry for making you wait this long for this feature.
Don't forget, I'm waiting for your comments!

Have fun,
Vassil