It's not really the convention of REST APIs to provide WADL/WSDL, but
it's something we'll consider for the next major release of the API.

On Thu, Oct 9, 2008 at 8:14 PM, jim.renkel <[EMAIL PROTECTED]> wrote:
>
> Lukas,
>
> Thank you for the pointer to and the effort put into creating the WADL
> and WSDL.
>
> I'm new to the group, and to Twitter for that matter, but I'm somewhat
> surprised that there aren't an official WADL and WSDL for the service.
> Or any other complete specification that I can find. Am I missing
> something?
>
> I would strongly suggest that official WADL and WSDL be developed and
> maintained.
>
> Comments appreciated in advance.
>
> Jim Renkel
>
> On Sep 29, 1:01 pm, "Lukas Jungmann" <[EMAIL PROTECTED]> wrote:
>> Hi Alex,
>>
>> On Mon, Sep 29, 2008 at 7:36 PM, Alex Payne <[EMAIL PROTECTED]> wrote:
>>
>> > This is a great idea, and something I've been planning on doing since
>> > the API became my full-time job several weeks ago.  Thanks for the
>> > suggetion, DeWitt!
>>
>> in case you'll (or anyone else) find WADL for the API and/orXMLschemafor API 
>> responses useful for the community, you can find them
>> at:http://tinyurl.com/4sh8e2
>>
>> I'm not saying it's perfect but can be a good start...
>>
>> regards,
>> --lj
>>
>>
>>
>> > On Sun, Sep 28, 2008 at 12:07 PM, DeWitt Clinton <[EMAIL PROTECTED]> wrote:
>> >> Hi Alex, and all,
>>
>> >> I was upgrading the java-twitter and python-twitter libraries recently,
>> >> partly in anticipation of the upcoming changes to the JSON format, and I
>> >> realized something that might be of great benefit to the community of
>> >> Twitter api library authors.
>>
>> >> Part of my testing strategy is to collect real-world results and run them
>> >> through each library as a way of smoke testing each call.  To date, I've
>> >> been collecting sample data myself by running queries using my own test
>> >> accounts.
>>
>> >> However, if would be even better if Twitter published a collection of
>> >> canonical test datasets corresponding to the various API calls.  That way
>> >> every library author could use the same sample data to test against, and 
>> >> we
>> >> could be sure that our code matched the Twitter API's expectations.
>>
>> >> For example, what if Twitter maintained a public read-only SVN repository
>> >> that contained sample data files like the following:
>>
>> >> public_timeline.json:
>>
>> >>> GEThttp://twitter.com/statuses/public_timeline.json
>>
>> >>> [{"user":{"followers_count":66, ...
>>
>> >> public_timeline.atom:
>>
>> >>> GEThttp://twitter.com/statuses/public_timeline.atom
>>
>> >>> <?xmlversion="1.0" encoding="UTF-8"?>
>> >>> <feedxml:lang="en-US" xmlns="http://www.w3.org/2005/Atom";>
>>
>> >>>   <title>Twitter public timeline</title>
>> >>>   <id>tag:twitter.com,2007:Status</id>
>> >>>   <link href="http://twitter.com/public_timeline"; type="text/html"
>> >>> rel="alternate"/>
>>
>> >>>   <updated>2008-09-28T18:48:13+00:00</updated>
>> >>>   <subtitle>Twitter updates from everyone!</subtitle>
>> >>>     <entry>
>> >>>         ...
>>
>> >> user_timeline.xml:
>>
>> >>> GET testuser:[EMAIL PROTECTED]://twitter.com/statuses/user_timeline.xml
>>
>> >>> <?xmlversion="1.0" encoding="UTF-8"?>
>> >>> <statuses type="array">
>> >>> <status>
>> >>> <created_at>Sun Sep 28 17:09:33 +0000 2008</created_at>
>> >>> <id>938260897</id>
>> >>> <text>As of midnight last night, I've been getting a 3G signal on my
>> >>> T-Mobile device in San Francisco, CA.</text>
>> >>> <source>web</source>
>> >>> <truncated>false</truncated>
>> >>> ...
>>
>> >> And so on and so forth for each permutation of the various API calls and
>> >> formats.  They should be versioned (perhaps using SVN tags) so we can test
>> >> against past and upcoming API changes as well.  This is especially 
>> >> valuable
>> >> for non-idempotent state-changing POST calls (which are the majority), 
>> >> where
>> >> it is difficult to maintain a stable set of test data between versions.
>>
>> >> Yes, it would be a little bit of work on the Twitter side, but it could
>> >> likely be automated.  Moreover, this would have the advantage of being
>> >> official data for us to test against, which like a pretty reasonable 
>> >> request
>> >> if the community is going to continue to maintain and develop libraries 
>> >> that
>> >> are expect to work as the Twitter API is updated and potentially 
>> >> introduces
>> >> non-backward compatible changes.
>>
>> >> What do you think?
>>
>> >> Cheers,
>>
>> >> -DeWitt
>>
>> > --
>> > Alex Payne - API Lead, Twitter, Inc.
>> >http://twitter.com/al3x
>



-- 
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x

Reply via email to