TsubuyakiSoup ドキュメント

はじめに

　Twitterは2006年にサービスが開始され、最近ではインターネットの枠を超えて、テレビや雑誌で話題になっています。HSPユーザの中にもTwitterのアカウントを持っている方が多いんじゃないでしょうか。
　HSPからもBASIC認証を使って、Twitterを操作することができました。しかし、2010年8月にてBASIC認証が廃止されてしまいました。これによって認証方式の選択肢がOAuthかxAuthしかなくり、HSPからTwitterを操作することは難しくなりました。
　その問題を解決するのが、このTsubuyakiSoupです。このモジュールをインクルードするだけで簡単にTwitterを操作できるようになります。 TwitterAPIやSearchAPIへのアクセス、OAuthでネックとなっていたシグネチャの生成などをサポートしています。

OAuthのしくみ

TwitterAPIでは、認証方式にOAuthを採用しています。OAuthというのは、ユーザがクライアント（コンシューマ）にパスワードを預けることなく、Twitter（プロバイダ）へのアクセス権を得るという新しい認証方式です。ここでは、そのOAuthの簡単な仕組みを説明します。詳しい仕組みについては、参考サイトを参照してください。

OAuthでの認証の手順

あらかじめ、クライアント情報をTwitterに登録し、Twitterから「Cousumer key」と「Cousumer Secret」を取得しておきます（取得の仕方は「Consumer Key & Consumer Secretの取得」の項で説明しています）。このConsumer Key&Secretは、クライアントがTwitterへアクセスするためのもので、いわゆるクライアントのパスワードのようなものです。

(1)　クライアントはConsumerKey等を元に署名（シグネチャ）を生成し、その署名等を引数にしてTwitterAPI「oauth/request_token」を実行して、リクエストトークン(token&token secret)を取得します。

(2)　返ってきたリクエストトークンを引数に指定して、webブラウザ（クライアント内部のブラウザでも可）でTwitterAPI「oauth/authorize」にアクセスします。

(3)　ユーザはブラウザ上でTwitterにログインし、クライアントにアクセス権を譲渡するかどうかを判断します。ユーザが許可した場合、PINがTwitterから発行され、ブラウザ上に表示されます。そのPINを、ユーザにクライアントへ入力してもらいます。

(4)　入力してもらったPINやリクエストトークンなどを元に署名を生成、その署名等を引数にしてTwitterAPI「oauth/access_token」を実行して、アクセストークン(token2&token secret2)を取得します。
取得したアクセストークンとConsumerセット等を使って各TwitterAPIを実行します。

※アクセストークンの使用期限は無期限です（2010年10月現在）。保存しておくことで、何度も認証作業を繰り返す必要がありません。しかし、アクセストークンは、ユーザのユーザ名とパスワードと同じ機能を持っています。暗号化して保存するなど、管理には気をつけてください。

以上の面倒な手順をTsubuyakiSoupモジュールで簡単に実装することができます。詳しくは、サンプルスクリプト「Sample01_OAuth.hsp」を参照してください。

xAuthでの認証の手順

xAuthというのは、OAuthの簡易版でありデスクトップアプリケーション向けの認証方式です。HSPでクライアント等を作る場合は、大抵こちらの認証方式を使用するでしょう。 xAuthを使うには、Twitter(api@twitter.com)へ利用申請メールを英語で送る必要があります（Twitter developers:Using xAuth）。
メールには、以下のことを書くといいようです。

アプリケーション名
ConsumerKey
アプリケーションの詳細
アプリケーションのスクリーンショット（添付することができないので、何かしらのサービスにアップしてそのURLを提示）
自分のアカウント

英語でのメールはハードルが高めだと思います。例文を載せておくので活用してみてください。

Hello.
I want permission that uses the xAuth.
I developing "アプリケーション名" now.
"アプリケーション名" is desktop application for use Twitter more eisily.
Its screen-shot is "スクリーンショットURL".
This application's ConsumerKey is "Consumer key".
my account is @xxxx
Thank you.

次にアクセストークンの取得方法です。

(1)　ユーザにダイアログ等を使って、ユーザ名（スクリーン名）とパスワードを入力してもらいます。

(2)　クライアントはConsumerKeyやユーザ名（スクリーン名）、パスワード等を元に署名（シグネチャ）を生成し、その署名等を引数にしてTwitterAPI「oauth/access_token」を実行して、アクセストークン(token2&token secret2)を取得します。
取得したアクセストークンとConsumerセット等を使って各TwitterAPIを実行します。

※アクセストークンの使用期限は無期限です（2010年10月現在）。保存しておくことで、何度も認証作業を繰り返す必要がありません。しかし、アクセストークンは、ユーザのユーザ名とパスワードと同じ機能を持っています。暗号化して保存するなど、管理には気をつけてください。
※入力してもらったパスワードは保存しないでください。使用後は、すぐ破棄するべきです。

以上の面倒な手順をTsubuyakiSoupモジュールで簡単に実装することができます。詳しくは、サンプルスクリプト「Sample02_xAuth.hsp」を参照してください。

Consumer Key & Consumer Secretの取得

　OAuthを使うには、Consumer KeyとConsumer Secretが必要になります。このConsumer KeyとConsumer Secretは、以下の通りにクライアントをTwitterに登録することで取得できます。
　まず、Twitterのアプリケーション登録へアクセスし、ログインしてください。次に各項目を入力してください。ユーザがアプリケーションを承認する際に表示されます。ユーザがアプリケーションを信頼できると判断できる材料は限られています。できるだけ詳細に記入したほうがいいと思われます。

アプリケーション名	アプリケーションの名前を入力します。
アプリケーションの説明	アプリケーションの説明を入力します。
アプリケーションのウェブサイトURL	アプリケーションの紹介や配布するページのURLを記入してください。登録したアプリケーションから投稿する際に投稿元としてこのURLにリンクが張られることになります。
所属会社／団体	開発者が個人ならHN、グループならグループ名でいいでしょう。または、Webサイトのタイトルでも良いと思います。
アプリケーションの種類	「クライアントアプリケーション」か「ブラウザアプリケーション」かを選択します。TsubuyakiSoupはクライアントアプリケーションを前提に書かれています。
Default Access Type	「Read & Write」か「Read-only」かを選択します。アプリケーションから投稿する機能を持たせる場合は「Read & Write」を選択してください。
アプリケーションのアイコン	アイコンがある場合はアイコンを指定します。アイコンが必要ない、用意出来ていないならそのままで大丈夫です。

最後に画像に表示されている英単語を入力してください。
「アプリケーションを登録する」ボタンを押すと「TWITTER API TERMS OF SERVICE」が表示されるので、よく読んだ上で「I Accept」ボタンを押してください。
ページが遷移し、アプリケーションの詳細が表示されますので、Cousumer KeyとCousumer Secretを確認してください。

RT＆QTについて

　ここで紹介するのは、Twitterでのユーザ間に広まった文化です。Twitterの正式なルールではありません。特にRTとQTの使い分けについては、個人の自由であって絶対にそうしなければならないというルールはありません。Twitterを利用したりクライアントを作成したりする際の参考として読んでください。

　RTとは、「ReTweet（リツイート）」の略語です。Retweetというのは、「再ツイート（転載）」の意味の造語で、自分が気にいったり興味をもったりしたツイートを多くの人へ広めようというTwitterユーザ間に広まった文化です。2009年に公式にReTweet機能が実装され、公式の機能を使用したRTを「公式RT」今まで通りのRTを「非公式RT」と呼ぶようになりました。

公式RT

　Twitterに実装されたReTweet機能です。本家Webサイトでは、リツイートしたいツイートにマウスカーソルを乗せるとツイートの右下にリツイートアイコンがでるので、それをクリックし、「はい」を押すことでリツイートすることが出来ます。リツイートのタイムラインは、サイドバーのリンク「リツイート」で確認できます。
　APIでもReTweet機能が実装されています。詳しくは、%%APIについて%%を参照してください。

非公式RT

　非公式RTにはいくつかの書式があります。

RT @ユーザ名元のツイート

RT 元のツイート (via @ユーザ名)

RT (via @ユーザ名) 元ツイートURL

他にもあります(*1)が、大別するとこの３種類です。主流なのは

RT @ユーザ名元のツイート

だと思われます。
　コメントを付け加えたい場合は、RTの前にコメントを挿入します。
例えば、Aさんの

〇〇の映画、製作だって！

というツイートをRTしたい場合は、

RT @A 〇〇の映画、製作だって！

としたり、コメントをつけて

情報ソースありますか？ RT @A 〇〇の映画、製作だって！

としたりします。

　RTの他にQTというものがあります。QTは「QuoteTweet」の略語で、「引用ツイート」の意味の造語です。RTと同じく誰かのツイートを引用し、コメントをつけて使用します。Twitterユーザさん達のブログの「RT/QTを使いわけよう」という意のエントリーやコメントを発端に広まり始めました。
　RTとの違いは、コメントの有無です。RTは「再ツイート（転載）」でありコメントを含まず、QTはあるツイートを引用してコメントを付けたいときに使用します。

QT

非公式RTの「RT」の部分を「QT」に変えるだけです。

コメント QT @ユーザ名元のツイート」

Twitterクライアント「Tween」でのQT

　Twitterクライアント「Tween」で実装されているQTは、上記のQTとは少し違う点があります。元のツイートへの「in_reply_to_status_id」を含むことです。「in_reply_to_status_id」というのは、ツイートに含まれる情報でどのツイートへの返信なのかを明示することができます。詳しくは%%API%% 「in_reply_to_status_id」を含むことでRTの公開範囲をReply（返信）と同じ範囲にでき、また元のツイートが改変されることがない等のメリットがあります。

　クライアントによっては、非公式RTやQTの挙動を選択できるものもあります。また、クライアントを作成する場合には、同じようにRTやQTの挙動を選択・指定できるようにすると親切かもしれません。

(*1):「RT」の部分が「RT:」とコロンがつくなど。詳しくは、下記でも紹介していますが、参考サイト「floatingdays-Twitterでの RTの書き方いろいろ」を参照してください。

参考サイト：
聴く耳を持たない(片方しか)-Twitterの公式RT、非公式RT、QTの違いを分かりやすく図で描いてみた
web-cinte.com-思想のないRTより、粗相のないvia
とかいろいろ-【Twitter】RT/via/RepostLink
floatingdays-Twitterでの RTの書き方いろいろ