APIドキュメントの読み方

2024年4月2日 22:43

APIを使いたいけどAPIドキュメントのページを参照しても
一体、どこを読めばいいのかわからない
どこを読めばいいのかわからないというより、
どう読んで、どう理解して、コードに反映させればいいのかわからない
ってなったのでTwitterのAPIドキュメントを参考に記事を書きました。

TwitterAPIの利用には以前にも記事を書きましたが、https://note.com/shirotabistudy/n/n0ca51e140f97

便利なtweepyというライブラリーがあったから扱えたものの、そのようなライブラリーが用意されていなかったら？どうすればAPIにリクエストをすればええねんってなったときのための備忘録

まずTwitterのAPIドキュメント

びっくりするくらい何をどうすればいいのかわかりませんでした。
１つずつ読み解いていきます。

1. APIを使うときはimport requestsを使う

標準ライブラリーで用意されています。

2. GET,POST,PUT,DELETEなどのHTTPメソッドの種類を見る

次にHTTPメソッドを見ます。

3. エンドポイントURLを確認する

https://api.twitter.com/2/tweetsだそうです。

4. 認証プロセスに使える方法を確認する

今回はOAuth1.0aを使います。＊理由については記事末尾記載　

5.　パラメータの生成方法を調べる

JSON body parameters
→JSON形式でパラメータを設定できるそうです。
Name列の値 => keyの値
Type列の値　=> valueに入れる値の型

上記の1〜５をまとめます。
1. APIを使うときはimport requestsを使う
2. GET,POST,PUT,DELETEなどのHTTPメソッドの種類を見る
→POST
3. エンドポイントURLを確認する
　→https://api.twitter.com/2/tweets
4. 認証プロセスに使える方法を確認する
　→OAuth1.0aを使います。
5.　パラメータの生成方法を調べる
→ keyは"text", valueはstringで指定します。
　e.g.) {'text' : 'Hello World!'}

ここでOAuth1.0aについてもう少し調査が必要そうなので、リンクを辿ってみました。

何言ってんだこいつ状態でしたが、落ち着いて読んでみると、
You have to sign each API request by passing several generated keys and tokens in an authorization header.
→生成されたいくつかのキーとトークンをauthorization headerで渡して、各 API リクエストに署名する必要があります。by Google翻訳

oauth_counsumer_key,
oauth_consumer_secret,
oauth_token,
oauth_token_secret
の４つのAPI Keyが必要みたいです。

で、pythonでOAuth1を手軽に実装できるライブラリーがあるのでぜひ活用する

以下が1〜5をまとめたコードです。

# 1. requestsを使う
import requests
from requests_oauthlib import OAuth1

# 3.　エンドポイントURL
url = "https://api.twitter.com/2/tweets"

# 4. 認証情報
consumer_key = *************
consumer_secret = *************
access_token = *************
access_token_secret = *************

# OAuth1 セッションを作成
auth = OAuth1(consumer_key, 
              consumer_secret, 
              access_token, 
              access_token_secret)



# 5. 投稿するツイートの内容はJSON形式
payload = {"text": "Hello World!"}

# 2. POSTでリクエストを送信
response = requests.post(url, json=payload, auth=auth)

# 応答を確認
if response.status_code == 201:
    print("ツイート成功!")
    print(response.json())
else:
    print(f"Error: {response.status_code} - {response.text}")

実行に成功すると

ツイート成功!
{'data': {'edit_history_tweet_ids': [123456789'], 
'id': '123456789', 'text': 'Hello World!'}}

こんな感じで１つずつ読み解いていったら実装できました！
TwitterAPIのアクセストークンの取得方法については過去記事を参照してください

OAuth 2.0 Authorization Code with PKCE (Proof Key for Code Exchange) を直接 requests ライブラリで実装することは可能ですが、いくつかの理由から複雑であり、特にウェブアプリケーションやモバイルアプリケーションのコンテキストで一般的に使用されます。ここでは、なぜこの認証フローを直接使用しなかったのか、その理由を詳しく説明します。

OAuth 2.0 Authorization Code with PKCE の複雑さ

複数ステップの認証プロセス: OAuth 2.0 Authorization Code with PKCE 認証フローは、セキュアな認証を提供するために複数のステップを必要とします。これには、認証コードの取得、コードと交換するためのプルーフキーの生成、最終的にアクセストークンを取得するステップが含まれます。各ステップで正確なパラメータを使用し、適切なエンドポイントにリクエストを送信する必要があります。
リダイレクトとコールバックの処理: 認証コードを取得する過程では、ユーザーを認証サーバーのページにリダイレクトさせ、その後アプリケーションに戻るためのコールバックURLを処理する必要があります。このプロセスは、ウェブサーバーまたはウェブフレームワークがないと実装が難しい場合があります。
セキュリティ上の懸念: PKCEの実装はセキュリティを強化するためのものであり、正しく実装されていない場合はセキュリティリスクを引き起こす可能性があります。適切なコードチャレンジとコードベリファイアの生成、そしてこれらの値のセキュアな扱いが必要です。

なぜ OAuth 1.0a を選んだのか

OAuth 1.0a は、Twitter API のようなAPIとの通信において、長い間使用されてきた確立された認証プロトコルです。requestsライブラリとrequests-oauthlibライブラリの組み合わせを使うことで、OAuth 1.0a の署名プロセスを簡単に実装できます。これは、特にサーバーサイドスクリプトや簡単なスクリプトでAPIにアクセスしたい場合に便利です。

OAuth 2.0 はより最新で、特定のシナリオではOAuth 1.0aよりもセキュアな選択肢ですが、その実装の複雑さと、特定のユースケース（特にアプリケーション内認証が必要な場合）に特化しているため、すべてのケースでOAuth 1.0aを置き換えるわけではありません。

結論として、簡易スクリプトや特定の環境での利便性、実装の容易さから、ここではOAuth 1.0a認証の例を提示しました。OAuth 2.0 Authorization Code with PKCEを使用する場合は、より複雑な認証フローを管理できるライブラリやフレームワークを利用することをお勧めします。by ChatGPT

この記事が気に入ったらサポートをしてみませんか？