extending http

0 views
Skip to first unread message

harmanjd

unread,
Nov 4, 2009, 12:16:45 PM11/4/09
to TalkingPuffin
I wanted to extend the Http class so that I could use it for a call to
a different rest service that wouldn't give back the rate api.

Since I didn't want to call the publishRateLimitInfo method in my
class I changed Http class as follows

diff --git a/twitter-api/src/main/scala/org/talkingpuffin/twitter/
Http.scala b/twitter-api/src/main/scala/org/talkingpuffin/twitter/
Http.scala
index 1de41f4..ea868a8 100644
--- a/twitter-api/src/main/scala/org/talkingpuffin/twitter/Http.scala
+++ b/twitter-api/src/main/scala/org/talkingpuffin/twitter/Http.scala
@@ -89,12 +89,11 @@ class Http(user: Option[String], password: Option
[String]) extends Publisher {
* This path also reads from conn.getErrorStream() to populate the
twitterMessage field
* in the thrown exception.
*/
- private def getXML(conn: HttpURLConnection): Node = {
+ protected def getXML(conn: HttpURLConnection): Node = {
val response = conn.getResponseCode()
response match {
case 200 => {
- publishRateLimitInfo(conn)
- XML.load(conn.getInputStream())
+ parseXmlResponse(conn)
}
case _ => throw TwitterException({
var errMsg = ""
@@ -108,6 +107,11 @@ class Http(user: Option[String], password: Option
[String]) extends Publisher {
},response)
}
}
+
+ protected def parseXmlResponse(conn: HttpURLConnection): Node = {
+ publishRateLimitInfo(conn)
+ XML.load(conn.getInputStream())
+ }

private def publishRateLimitInfo(conn: HttpURLConnection) {
val rl = List("X-RateLimit-Remaining", "X-RateLimit-Limit", "X-
RateLimit-Reset").



-----------------------------------------


Then I overrode the parseXmlResponse method and removed the
publishRateLimitInfo() call.

I realize that if the headers aren't there then the
publishRateLimitInfo() call won't hurt anything, but I just didn't
want to even do it, since it would be pointless.

James



Dave Briccetti

unread,
Nov 4, 2009, 3:28:14 PM11/4/09
to TalkingPuffin
OK, James. I made a similar change. Ideally, if this code is to be
used outside of Twitter (that’s what you meant, right?), then all the
generic code (without TwitterException, the headers code, etc.) should
be pulled out into a separate class. But if this small change lets you
reuse without having to modify, then it’s OK with me.

I’ve been thinking there may be other classes we want to pull out for
easier reuse. Filtering, perhaps.

harmanjd

unread,
Nov 4, 2009, 4:24:18 PM11/4/09
to TalkingPuffin
Yeah - I am using several web services in my project. The client that
I am working on is a bot that looks at any mentions to the twitter
account and parses them to run a search in another service. The other
service has an rest xml api and so I am wanting to reuse the Http
class for those requests as well. I also make my own calls out to the
bitly api to shorten urls and it has a similar api.

The Http class in the twitter-api project is really nice for other
rest/xml request too especially with the retry support and error
handling built in.

Ideally it would be refactored so that the Http class didn't have any
twitter specific functionality and then have a TwitterHttp class that
had the additional twitter support. I don't have time right at the
moment to do that refactoring and submit it back as a patch - so I did
this hack instead.

Also the TwitterException class could really be renamed to
HttpException probably and used in a more generic sense, but it is
usable as is atm.

Thanks!
James
Reply all
Reply to author
Forward
0 new messages