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. D.
________________________________ Von: [email protected] im Auftrag von Vassil Dichev Gesendet: Mo 2/16/2009 08:28 An: [email protected] 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.
