Shulou(Shulou.com)06/02 Report--

This article mainly explains "what is Twitter". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is Twitter".

Twitter quickly occupied the Internet market. You must know that this excellent social networking tool allows subscribers to provide brief status updates about themselves and the tasks they are currently performing. Followers will receive updates to their Twitter feeds, much like blogs generate updates to blog readers' feeds.

For its part, Twitter is an interesting discussion of social networks and a new generation of "high connectivity" among users, with all the advantages and disadvantages you can think of.

Because Twitter released its API a long time ago, a large number of Twitter client applications flocked to Internet. Because the API is mainly built on an intuitive and easy-to-understand basis, many developers find it necessary to build their own Twitter client, much like developers learning Web technology to build their own blog server.

Given the functionality of Scala (which seems to work well with Twitter's REST-style features) and the excellent XML processing features, it should be a great experience to try to build a Scala client library for accessing Twitter.

What is Twitter?

Before we discuss it in detail, let's take a look at Twitter API.

To put it simply, Twitter is a "microblog"-short personalized feeds about yourself, no more than 140characters, which any "follower" can receive through Web updates, RSS, text messages, and so on. The 140-character limit comes entirely from text messages, which are the main source of Twitter and are subject to similar restrictions.

What do you mean by having the most REST features?

Some readers will be curious about the most REST-featured phrase I use; this requires some explanation. "Twitter API tries to conform to the design principles of Representational State Transfer (REST)." And to a large extent it did. Roy Fielding, the creator of the idea, may not agree that Twitter uses this term, but in terms of implementation, Twitter's approach will fit most people's REST definition. I just want to avoid a heated debate about the definition of REST. Therefore, I used the qualifier "most".

From a practical point of view, Twitter is an API with the most REST characteristics, and you can use some kinds of message formats-XML, ATOM, RSS, or JSON-to send or receive messages from Twitter servers. Different URL, combined with different messages and their required and optional message parts, can make different API calls. For example, if you want to receive a complete list of all "Tweets" (Twitter updates) from everyone on Twitter (also known as the "common timeline"), you need to prepare a XML, ATOM, RSS, or JSON message, send it to the appropriate URL, and use the result in the same format as on the Twitter website (apiwiki.twitter.com):

Public_timeline

Returns the custom user icon that is set

20 latest statuses for unprotected users. No authentication is required.

Note that the common timeline will be cached for 60 seconds

So frequent requests for it are no longer a waste of resources.

URL: http://twitter.com/statuses/public_timeline.format

Format: xml, json, rss, atom

Method: GET

API limit: not applicable

Return: list of status elements

Programmatically, this means that we send a simple GET HTTP request to the Twitter server, and we get a set of "status" messages encapsulated in XML, RSS, ATOM, or JSON messages. The Twitter site defines the status message as something similar to that shown in listing 1:

Listing 1. Hello World, where are you?

< feed xml:lang="en-US" xmlns="http://www.w3.org/2005/Atom">

< title>

Twitter / tedneward

< /title>

< id>

Tag:twitter.com,2007:Status

< /id>

< link type="text/html" rel="alternate" href="http://twitter.com/tedneward"/>

< updated>

2009-03-07T13:48:31+00:00

< /updated>

< subtitle>

Twitter updates from Ted Neward / tedneward.

< /subtitle>

< entry>

< title>

Tedneward: @ kdellison Happens to the best of us...

< /title>

< content type="html">

Tedneward: @ kdellison Happens to the best of us...

< /content>

< id>

Tag:twitter.com,2007: http://twitter.com/tedneward/statuses/1292396349

< /id>

< published>

2009-03-07T11:07:18+00:00

< /published>

< updated>

2009-03-07T11:07:18+00:00

< /updated>

< link type="text/html" rel="alternate" href="http://twitter.com/tedneward/statuses/1292396349"/>

< link type="image/png" rel="image" href="http://s3.amazonaws.com/twitter_production/profile_images/ 55857457/javapolis_normal.png"/>

< author>

< name>

Ted Neward

< /name>

< uri>

Http://www.tedneward.com

< /uri>

< /author>

< /entry>

< /feed>

Most, if not all, of the elements in the status message are intuitive, so I won't repeat them.

Because we can use Twitter messages in three XML-based formats, and because Scala has some very powerful XML features, including XML literals and XPath-like query syntax API, it takes only some basic Scala coding to write a Scala library that can send and receive Twitter messages. For example, using listing 1 messages to extract the title or content of status updates through Scala can take advantage of the XML type and\ and\ methods of Scala, as shown in listing 2:

Listing 2. Hello, Ted, where are you?

< ![CDATA[ package com.tedneward.scitter.test { class ScitterTest { import org.junit._, Assert._ @Test def simpleAtomParse = { val atom = < feed xml:lang="en-US" xmlns="http://www.w3.org/2005/Atom">

< title>

Twitter / tedneward

< /title>

< id>

Tag:twitter.com,2007:Status

< /id>

< link type="text/html" rel="alternate" href="http://twitter.com/tedneward"/>

< updated>

2009-03-07T13:48:31+00:00

< /updated>

< subtitle>

Twitter updates from Ted Neward / tedneward.

< /subtitle>

< entry>

< title>

Tedneward: @ kdellison Happens to the best of us...

< /title>

< content type="html">

Tedneward: @ kdellison Happens to the best of us...

< /content>

< id>

Tag:twitter.com,2007: http://twitter.com/tedneward/statuses/1292396349

< /id>

< published>

2009-03-07T11:07:18+00:00

< /published>

< updated>

2009-03-07T11:07:18+00:00

< /updated>

< link type="text/html" rel="alternate" href="http://twitter.com/tedneward/statuses/1292396349"/>

< link type="image/png" rel="image" href="http://s3.amazonaws.com/twitter_production/profile_images/ 55857457/javapolis_normal.png"/>

< author>

< name>

Ted Neward

< /name>

< uri>

Http://www.tedneward.com

< /uri>

< /author>

< /entry>

< /feed>

AssertEquals (atom\\ "entry"\ "title", "tedneward: @ kdellison Happens to the best of us...")}}]] >

For more details on XML support for Scala, see "Scala and XML".

In fact, using the original XML is not an interesting exercise in itself. If the purpose of Scala is to make our lives easier, you can create a class or set of classes designed to simplify the task of sending and receiving Scala messages. As one of the goals, you should be able to easily use the library in a "normal" Java program (which means it can be easily accessed from any environment that understands ordinary Java semantics, such as Groovy or Clojure).

API design

Before delving into the API design of the Scala/Twitter library (which I call "Scitter" at the suggestion of my colleague ThoughtWorker Neal Ford), there are a few requirements that need to be clear.

First of all, Scitter obviously has some dependence on network access-and can be extended to Twitter servers-which makes testing very difficult.

Second, we need to parse (and test) the various formats that Twitter sends back.

Third, we want to hide the differences between the various formats within API so that clients don't have to worry about the recorded Twitter message format, but can only use standard classes.

Finally, because Twitter relies on "authenticated users" to use a lot of API, the Scitter library needs to adapt to the difference between "authenticated" and "unauthenticated" API without making things too complicated.

Network access requires some form of HTTP communication in order to contact the Twitter server. Although we can use the Java library itself (especially the URL class and its siblings), because Twitter API requires a large number of request and response principal connections, it is easier to use different HTTP API, especially the Apache Commons HttpClient library. To make it easier to test the client API, the actual communication will be hidden in some API internal Scitter libraries to make it easier to switch to another HTTP library (the necessity is not easy to think of), and to simulate actual network traffic to simplify testing (the effect is easy to think of).

As a result, the first test is to Scala the HttpClient call to ensure that the basic communication mode is in place; note that because HttpClient relies on two other Apache libraries (Commons Logging and Commons Codec), you also need to provide these libraries at run time; for readers who want to develop similar kinds of code, make sure that all three libraries are included in the classpath.

Because the easiest to use Twitter API is to test API

So "ok" is returned in the request format with a 200 OK HTTP status code.

We will use it as a reservation clause in the Scitter test. It is located in URL http://twitter.com/help/test.format (where "format" is "xml" or "json"; for now, we will choose to use "xml"), and the only HTTP method supported is GET. The HttpClient code is simple and easy to understand, as shown in listing 3:

Listing 3. Twitter PING!

Package com.tedneward.scitter.test {class ExplorationTests {/ /... Import org.apache.commons.httpclient._, methods._, params._, cookie._ @ Test def callTwitterTest = {val testURL = "http://twitter.com/help/test.xml" / / HttpClient API 101 val client = new HttpClient () val method = new GetMethod (testURL) method.getParams () .setParameter (HttpMethodParams.RETRY_HANDLER, new DefaultHttpMethodRetryHandler (3) False) client.executeMethod (method) val statusLine = method.getStatusLine () assertEquals (statusLine.getStatusCode (), 200) assertEquals (statusLine.getReasonPhrase (), "OK")}

The most important part of this code is the HttpClient template-interested readers should consult the HttpClient API documentation for more information. Assuming that the network connected to the public Internet is available (and Twitter has not modified its public API), the test should pass smoothly.

In view of this, we examine the first part of the Scitter client in detail. This means that we need to solve a design problem: how to build Scitter clients to handle authenticated and unauthenticated calls. For now, I'll use the typical Scala approach, assuming that validation is performed "by object", so put the calls that need to be validated in the class definition and the unvalidated calls in the object definition:

Listing 4. Scitter.test

Package com.tedneward.scitter {/ * * Object for consuming "non-specific" Twitter feeds, such as the public timeline. * Use this to do non-authenticated requests of Twitter feeds. * / object Scitter {import org.apache.commons.httpclient._, methods._, params._, cookie._ / * * Ping the server to see if it's up and running. * Twitter docs say: * test * Returns the string "ok" in the requested format with a 200OK HTTP status code. * URL: http://twitter.com/help/test.format * Formats: xml, json * Method (s): GET * / def test: Boolean = {val client = new HttpClient () val method = new GetMethod ("http://twitter.com/help/test.xml") method.getParams (). SetParameter (HttpMethodParams.RETRY_HANDLER, new DefaultHttpMethodRetryHandler (3) False) client.executeMethod (method) val statusLine = method.getStatusLine () statusLine.getStatusCode () = 200}} / * * Class for consuming "authenticated user" Twitter APIs. Each instance is * thus "tied" to a particular authenticated user on Twitter, and will * behave accordingly (according to the Twitter API documentation). * / class Scitter (username: String, password: String) {}}

For now, let's put the network abstraction aside-add it later when offline testing becomes more important. This will also help avoid "excessive abstraction" of network traffic as we better understand how to use the HttpClient class.

Since there is a clear distinction between authenticated and unauthenticated Twitter clients, we will quickly create a validated method. It appears that Twitter provides an API that validates the user's login credentials. Again, the HttpClient code will be similar to the previous code, except that the user name and password are passed to the Twitter API.

This leads to the concept of how Twitter validates users. After a quick look at the Twitter API page, you can see that Twitter uses an Stock HTTP authentication method, which is the same as any authenticated resource in HTTP. This means that the HttpClient code must provide the user name and password as part of the HTTP request, not as the body of the POST, as shown in listing 5:

Listing 5. Hello, Twitter, it's me!

Package com.tedneward.scitter.test {class ExplorationTests {def testUser = "TwitterUser" def testPassword = "TwitterPassword" @ Test def verifyCreds = {val client = new HttpClient () val verifyCredsURL = "http://twitter.com/account/verify_credentials.xml" val method = new GetMethod (verifyCredsURL) method.getParams (). SetParameter (HttpMethodParams.RETRY_HANDLER, new DefaultHttpMethodRetryHandler (3) False) client.getParams () .setAuthenticationPreemptive (true) val defaultcreds = new UsernamePasswordCredentials (testUser, testPassword) client.getState () .setCredentials (new AuthScope ("twitter.com", 80, AuthScope.ANY_REALM), defaultcreds) client.executeMethod (method) val statusLine = method.getStatusLine () assertEquals StatusLine.getStatusCode () assertEquals ("OK", statusLine.getReasonPhrase ())}

Note that for this test to communicate smoothly, the username and password fields will need to enter what Twitter can accept-I used my own Twitter username and password when developing, but obviously you need to use your own username and password. Registering for a new Twitter account is fairly easy, so I assume you already have one or know how to register (fine). I will wait for this task to be completed.

When you are done, it is very simple to map it to the Scitter class using the username and password constructor parameters, as shown in listing 6:

Listing 6. Scitter.verifyCredentials

Package com.tedneward.scitter {import org.apache.commons.httpclient._, auth._, methods._, params._ / /... / * Class for consuming "authenticated user" Twitter APIs. Each instance is * thus "tied" to a particular authenticated user on Twitter, and will * behave accordingly (according to the Twitter API documentation). * / class Scitter (username: String, password: String) {/ * * Verify the user credentials against Twitter. * * Twitter docs say: * verify_credentials * Returns an HTTP 200OK response code and a representation of the * requesting user if authentication was successful; returns a 401status * code and an error message if not. Use this method to test if supplied * user credentials are valid. * URL: http://twitter.com/account/verify_credentials.format * Formats: xml, json * Method (s): GET * / def verifyCredentials: Boolean = {val client = new HttpClient () val method = new GetMethod ("http://twitter.com/help/test.xml") method.getParams (). SetParameter (HttpMethodParams.RETRY_HANDLER, new DefaultHttpMethodRetryHandler (3) False) client.getParams () .setAuthenticationPreemptive (true) val creds = new UsernamePasswordCredentials (username, password) client.getState () .setCredentials (new AuthScope ("twitter.com", 80, AuthScope.ANY_REALM), creds) client.executeMethod (method) val statusLine = method.getStatusLine () statusLine.getStatusCode () = 200}

The corresponding Scitter class test in listing 7 is also fairly simple:

Listing 7. Test Scitter.verifyCredentials

Package com.tedneward.scitter.test {class ScitterTests {import org.junit._, Assert._ import com.tedneward.scitter._ def testUser = "TwitterUsername" def testPassword = "TwitterPassword" / /... @ Test def verifyCreds = {val scitter = new Scitter (testUser, testPassword) val result = scitter.verifyCredentials assertTrue (result)}

It's not so bad. The basic structure of the library has taken shape, but it is clear that there is still a long way to go, especially since no Scala-specific tasks are actually performed at the moment-in object-oriented design, library construction is not as simple as practice. So we started using some XML and returned it in a more reasonable format.

From XML to object

The simplest API you can add now is public_timeline, which collects the latest n updates received by Twitter from all users and returns them for ease of use. Unlike the other two API discussed earlier, public_timeline API returns a response body (rather than just relying on the status code), so we need to decompose the generated XML/RSS/ATOM/, and return it to the Scitter client.

Now, let's write a discovery test that accesses the public feed and dumps the results to stdout for analysis, as shown in listing 8:

Listing 8. What's everybody up to?

Package com.tedneward.scitter.test {class ExplorationTests {/... @ Test def callTwitterPublicTimeline = {val publicFeedURL = "http://twitter.com/statuses/public_timeline.xml" / / HttpClient API 101 val client = new HttpClient () val method = new GetMethod (publicFeedURL) method.getParams () .setParameter (HttpMethodParams.RETRY_HANDLER, new DefaultHttpMethodRetryHandler (3) False) client.executeMethod (method) val statusLine = method.getStatusLine () assertEquals (statusLine.getStatusCode (), 200) assertEquals (statusLine.getReasonPhrase (), "OK") val responseBody = method.getResponseBodyAsString () System.out.println ("callTwitterPublicTimeline got..." ") System.out.println (responseBody)}

After running, the result will be different each time, because there are many users on the public Twitter server, but it should usually be similar to the JUnit text file dump in listing 9:

Listing 9. Our Tweets results

< statuses type="array">

< status>

< created_at>

Tue Mar 10 03:14:54 + 0000 2009

< /created_at>

< id>

1303777336

< /id>

< text>

She really is. Http://tinyurl.com/d65hmj

< /text>

< source>

< a href="http://iconfactory.com/software/twitterrific">

Twitterrific

< /a>

< /source>

< truncated>

False

< /truncated>

< in_reply_to_status_id>

< /in_reply_to_status_id>

< in_reply_to_user_id>

< /in_reply_to_user_id>

< favorited>

False

< /favorited>

< user>

< id>

18729101

< /id>

< name>

Brittanie

< /name>

< screen_name>

Brittaniemarie

< /screen_name>

< description>

I'm a bright character. I suppose.

< /description>

< location>

Atlanta or Philly.

< /location>

< profile_image_url>

Http://s3.amazonaws.com/twitter_production/profile_images/ 81636505/goodish_normal.jpg

< /profile_image_url>

< url>

Http://writeitdowntakeapicture.blogspot.com

< /url>

< protected>

False

< /protected>

< followers_count>

sixty-one

< /followers_count>

< /user>

< /status>

< status>

< created_at>

Tue Mar 10 03:14:57 + 0000 2009

< /created_at>

< id>

1303777334

< /id>

< text>

Number 2 of my four life principles. "Life is fun and rewarding"

< /text>

< source>

Web

< /source>

< truncated>

False

< /truncated>

< in_reply_to_status_id>

< /in_reply_to_status_id>

< in_reply_to_user_id>

< /in_reply_to_user_id>

< favorited>

False

< /favorited>

< user>

< id>

21465465

< /id>

< name>

Dale Greenwood

< /name>

< screen_name>

Greeendale

< /screen_name>

< description>

Vegetarian. Eat and use only organics. Love helping people become prosperous

< /description>

< location>

Melbourne Australia

< /location>

< profile_image_url>

Http://s3.amazonaws.com/twitter_production/profile_images/ 90659576/Dock_normal.jpg

< /profile_image_url>

< url>

Http://www.4abundance.mionegroup.com

< /url>

< protected>

False

< /protected>

< followers_count>

fifteen

< /followers_count>

< /user>

< /status>

(A lot more have been snipped)

< /statuses>

By looking at the result and the Twitter document, you can see that the result of the call is a set of simple "status" messages with a consistent message structure. XML using Scala to support separation of results is fairly simple, but we simplify them as soon as the basic tests pass, as shown in listing 10:

Listing 10. What's everybody up to?

Package com.tedneward.scitter.test {class ExplorationTests {/... @ Test def simplePublicFeedPullAndParse = {val publicFeedURL = "http://twitter.com/statuses/public_timeline.xml" / / HttpClient API 101 val client = new HttpClient () val method = new GetMethod (publicFeedURL) method.getParams () .setParameter (HttpMethodParams.RETRY_HANDLER, new DefaultHttpMethodRetryHandler (3) False) val statusCode = client.executeMethod (method) val responseBody = new String (method.getResponseBody ()) val responseXML = scala.xml.XML.loadString (responseBody) val statuses = responseXML\\ "status" for (n

< - statuses.elements) { n match { case < status>

{contents @ _ *}

< /status>

= > {System.out.println ("Status:") contents.foreach ((c) = > c match {case

< text>

{t @ _ *}

< /text>

= > System.out.println ("\ tText:" + t.text.trim) case

< user>

{contents2 @ _ *}

< /user>

= > {contents2.foreach ((c2) = > c2 match {case

< screen_name>

{u}

< /screen_name>

= > System.out.println ("\ tUser:" + u.text.trim) case _ = > ()} case _ = > ()} )} case _ = > () / / or If you prefer, System.out.println ("Unrecognized element!")}

As the sample code pattern changes, this is not recommended-it's a bit like DOM, navigating to each child element in turn, extracting the text, and then navigating to another node. I can execute only two XPath-style queries, as shown in listing 11:

Listing 11. Alternative analytical method

For (n)

< - statuses.elements) { val text = (n \\ "text").text val screenName = (n \\ "user" \ "screen_name").text } 这显然更加简短，但它带来了两个基本问题： 我们可以强制 Scala 的 XML 库针对每个元素或子元素遍历一次图，其速度会随时间减慢。 我们仍然需要直接处理 XML 消息的结构。这是两个问题中最为重要的。 也就是说，这种方式不具备可伸缩性 - 假设我们最终对 Twitter 状态消息中的每个元素都感兴趣，我们将需要分别从各状态中提取各个元素。 这又造成了另一个与各格式本身相关的问题。记住，Twitter 可以使用四种不同的格式，并且我们不希望 Scitter 客户机需要了解它们之间的任何差异，因此 Scitter 需要一个能返回给客户机的中间结构，以便未来使用，如清单 12 所示： 清单 12. Breaker，您的状态是什么？ abstract class Status { val createdAt : String val id : Long val text : String val source : String val truncated : Boolean val inReplyToStatusId : Option[Long] val inReplyToUserId : Option[Long] val favorited : Boolean val user : User } 这与 User 方式相类似，考虑到简洁性，我就不再重复了。注意，User 子元素有一个有趣的问题 - 虽然存在 Twitter 用户类型，但其中内嵌了一个可选的 "最新状态"。状态消息还内嵌了一个用户。对于这种情况，为了帮助避免一些潜在的递归问题，我选择创建一个嵌入在 Status 内部的 User 类型，以反映所出现的 User 数据；反之亦然，Status 也可以嵌入在 User 中，这样可以明确避免该问题。（至少，在没发现问题之前，这种方法是有效的）。 现在，创建了表示 Twitter 消息的对象类型之后，我们可以遵循 XML 反序列化的公共 Scala 模式：创建相应的对象定义，其中包含一个 fromXml 方法，用于将 XML 节点分离到对象实例中，如清单 13 所示： 清单 13. 分解 XML /** * Object wrapper for transforming (format) into Status instances. */ object Status { def fromXml(node : scala.xml.Node) : Status = { new Status { val createdAt = (node \ "created_at").text val id = (node \ "id").text.toLong val text = (node \ "text").text val source = (node \ "source").text val truncated = (node \ "truncated").text.toBoolean val inReplyToStatusId = if ((node \ "in_reply_to_status_id").text != "") Some((node \"in_reply_to_status_id").text.toLong) else Noneval inReplyToUserId = if ((node \ "in_reply_to_user_id").text != "") Some((node \"in_reply_to_user_id").text.toLong) else Noneval favorited = (node \ "favorited").text.toBoolean val user = User.fromXml((node \ "user")(0)) } } } 其中最强大的一处是，它可以针对 Twitter 支持的其他任何格式进行扩展 - fromXml 方法可以在分解节点之前检查它是否保存了 XML、RSS 或 Atom 类型的内容，或者 Status 可以包含 fromXml、fromRss、fromAtom 和 fromJson 方法。实际上，后一种方法是我的优先选择，因为它会平等对待基于 XML 的格式和 JSON（基于文本）格式。 好奇和细心的读者会注意到在 Status 及其内嵌 User 的 fromXml 方法中，我使用的是 XPath 样式的分解方法，而不是之前建议的遍历内嵌元素的方法。现在，XPath 样式的方法看上去更易于阅读，但幸运的是，我后来改变了注意，良好的封装仍然是我的朋友 - 我可以在随后修改它，Scitter 外部的任何人都不会知道。 注意 Status 内部的两个成员如何使用 Option[T] 类型；这是因为这些元素通常排除在 Status 消息外部，并且虽然元素本身会出现，但它们显示为空（类似于 < in_reply_to_user_id>

< /in_reply_to_user_id>

). This is what Option [T] is for. When elements are empty, they use the "None" value. This means that accessing them is more difficult because of Java-based compatibility, but the only viable way is to call get () on the resulting Option instance, which is less complex and solves the "either null or zero" problem.

It is now easy to use the common timeline:

Listing 14. Decompose the common timeline

@ Test def simplePublicFeedPullAndDeserialize = {val publicFeedURL = "http://twitter.com/statuses/public_timeline.xml" / / HttpClient API 101 val client = new HttpClient () val method = new GetMethod (publicFeedURL) method.getParams () .setParameter (HttpMethodParams.RETRY_HANDLER, new DefaultHttpMethodRetryHandler (3) False) val statusCode = client.executeMethod (method) val responseBody = new String (method.getResponseBody ()) val responseXML = scala.xml.XML.loadString (responseBody) val statuses = responseXML\\ "status" for (n <-statuses.elements) {val s = Status.fromXml (n) System.out.println ("\ tasking @" + s.user.screenName + "'wrote" + s.text)}}

Obviously, this looks more concise and easy to use.

Combining all of this into a single instance of Scitter is fairly simple, involving only executing queries, parsing individual Status elements, and adding them to the List [Status] instance, as shown in listing 15:

Listing 15. Scitter.publicTimeline

Package com.tedneward.scitter {import org.apache.commons.httpclient._, auth._, methods._, params._ import scala.xml._ object Scitter {/ /... / * Query the public timeline for the most recent statuses. * * Twitter docs say: * public_timeline * Returns the 20 most recent statuses from non-protected users who have set * a custom user icon. Does not require authentication. Note that the * public timeline is cached for 60 seconds so requesting it more often than * that is a waste of resources. * URL: http://twitter.com/statuses/public_timeline.format * Formats: xml, json, rss Atom * Method (s): GET * API limit: Not applicable * Returns: list of status elements * / def publicTimeline: List [Status] = {import scala.collection.mutable.ListBuffer val client = new HttpClient () val method = new GetMethod ("http://twitter.com/statuses/public_timeline.xml") method.getParams () .setParameter (HttpMethodParams.RETRY_HANDLER) New DefaultHttpMethodRetryHandler (3 False) client.executeMethod (method) val statusLine = method.getStatusLine () if (statusLine.getStatusCode () = 200) {val responseXML = XML.loadString (method.getResponseBodyAsString ()) val statusListBuffer = new ListBuffer [Status] for (n <-(responseXML\\ "status") .elements) statusListBuffer + = (Status.fromXml ( N) statusListBuffer.toList} else {Nil}

It is clear that we still have a long way to go before implementing a full-featured Twiter client. But so far, we have achieved basic behavior.

Thank you for your reading, the above is the content of "what is Twitter", after the study of this article, I believe you have a deeper understanding of what Twitter is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.