CAMPFIRE, inc. Takumi Abe 外部サービス提供のAPI を利用する 機能を作るときの頭の中 

Takumi Abe { 　" 普段" : { 　　" 会社": " 株式会社CAMPFIRE", 　　" 職種": "Web バックエンドエンジニア", 　　" 趣味": [ " 書道", " お酒" ] 　}, 　" コミュニティ活動": [ 　　"JAWS-UG おおいた", 　　"JAWS PANKRATION 2021 実行委員", 　　"AWS Comunity Builder(Serverless)", 　　"JAWS FESTA 2023" 　], } } 

ことの始まりは些細なことだった... 

面白そうですね！ ユーザーもほしそう！ あべたく D ◯s ◯r ◯の垢情報とか連携できたら， もっとサービス拡張できそうだよね！ 

さてさてさ〜て，始めるとしますか〜 そもそもだけど，外部API との連携機能って ログインぐらいしか詳しく知らんからとりまぐぐって👀 ..... この機能ってClient がユーザーごとで違う... あっ.... あべたく 

あれ... そもそもこんな実装してる事例 見たことないんだが... ここまでやって気づく API キーをDB に登録すること自体があまり推奨されてない （いやそりゃそう.... ） 必然的にルールもこれから作る... 

とりあえず，今ある知識と 外部API の取り扱いの注意事項を整理 してできる限りで実装してみよう 

前提事項 使用言語はRuby Ruby on Rails 6 系でのWeb 開発 サービスは既に数年稼働していて， アーキテクチャはWEB サービスで基本的な EC2 + RDS ..( 以下略を想定 外部API はできる限り，EOL までが長いVersion での実装が希望 

外部API を使う上で 気をつけること 

https://zenn.dev/sky/articles/6f79982ca89ea3 超精密に知りたい方はこちら！！！ 

最新のメンテ状況，SDK があるか，権限周りは...etc. ドキュメントをしっかり読む API がエラーしたときのデータがずれることが無い ように処理順やリトライ/ 例外処理をきちんと定義 トランザクション管理ができている だれがなんの操作をしてるのかチェックできるように！ req/res のログを取る 一番気をつかう... きちんと暗号化されてる？ トークンやキーの保管/ 運用方法を決める どこまでが自分たちでの守備範囲かをきめておく！！ 連携解除( データ破棄) の仕様を決めておく 放置すると途中からAPI の仕様を理解してる人減る 自分以外にも分かる人/ ドキュメントを作る 阿部的に 外部API を使用する開発で 気をつけた/ 今後気をつけること 

最新のメンテ状況，SDK があるか，権限周りは...etc. ドキュメントをしっかり読む API がエラーしたときのデータがずれることが無い ように処理順やリトライ/ 例外処理をきちんと定義 トランザクション管理ができている だれがなんの操作をしてるのかチェックできるように！ req/res のログを取る 一番気をつかう... きちんと暗号化されてる？ トークンやキーの保管/ 運用方法を決める どこまでが自分たちでの守備範囲かをきめておく！！ 連携解除( データ破棄) の仕様を決めておく 放置すると途中からAPI の仕様を理解してる人減る 自分以外にも分かる人/ ドキュメントを作る 阿部的に 外部API を使用する開発で 気をつけた/ 今後気をつけること 

トークンやキーの 保管/ 運用方法を 決める ユーザー情報などと分けることで権限レベルを設定しやすくする 不正アクセス防止のために機密情報は載せない コードレビューのときに注意 1 管理テーブルを分ける 3 リフレッシュのタイミング 2 キーをログに残さない API を同時に叩いてエラーとかは全然あり得る 必ずトークンは1 つを参照，複数ある場合は有効なもの以 外はロック，アクセス不可にするなどで対応 4 DB に保存するならまず暗号化 フレームワークに搭載されているものを使うなり，KMS などを使うなりで対応 

暗号化の候補 ActiveRecord モデルの特定の属性を暗号化するためのgem https://github.com/attr-encrypted/attr_encrypted Rails 側で保存するのは暗号化された値とKMS で管理してる暗号化キー AWS SDK で実装可能 attr_encrypted gem AWS Secrets Manager AWS KMS Rails 側で保存するのは対象のキー AWS SDK で実装可能 

ドキュメントを しっかり読む API のバージョンアップやISSUE を要チェック 公式ドキュメントに無いことや新規仕様は実際に動かして みたら早かったりする 自分の言語でSDK などが展開されてるかは重要，Client などを 作らなくてもよくなる ただし，これもAPI のバージョンやメンテ具合をよく見ておく 1 メンテ状況の把握 3 権限周り 2 SDK があるか GUI の操作でないと付与できないパターンも合ったりする Permission についてのページをじっくり見ていく （それに乗ってなかったら，ISSUE あげる） どうしても無いときは概要文を見てるとヒントがあるかも👀 

ドキュメントを しっかり読む バリめんどい... サービスによって統一されてるものもあれば，同じサ ービスでもエンドポイントによって違う，みたいなの もある💦 4 Rate 制限の把握 実例 User ステータスの変動に合わせて，post 処理を投げたい しかしRate 制限は抱えているユーザー数，更新が発生す る数を秒間でも超えてくる ．．．無理やりステータス管理させて回避してる.... 

Rate 制限 Sidekiq で実装👀 Job Sidekiq.yml Sidekiq とsidekiq-limit_fetch gem で対応可能 https://github.com/deanpcmad/sidekiq-limit_fetch 

Rate 制限 AWS で実装👀 SQS + Lambda で実現可能 しかし，Lambda にAPI キーなどを渡す必要が出てくる Secret Manager が必要になりそう💦 実行命令をキュー (+対象のuser_idとか） Access Tokenを登録 処理に必要な機密情報 規定並列処理数を 維持しつつ実行 

自分以外にも分かる人/ ドキュメントを作る 運用段階に入ってからでいいやではなく， 設計段階からAPI 仕様を把握しておく人を作る レビューもだが，リリース直後になにか問題が 発生した場合などの調査がつまらない/ 相談相手 がいるだけで精神的な安全を確保できる 

まとめ API キーの管理やクライアントの定義など様々なことが複雑化する 複雑化したものをいかに整理できるかやドキュメントなどで補完でき るかが勝負の鍵 連携機能としてユーザー提供する際には設計相談は入念に行う 制限内で安定稼働させるためにはキューなどの仕組みを使い同時実行数を制御 SDK で対策してる( 数秒待ってからリトライ) してる場合もあるから，要確認 Rate 制限には要注意 環境変数で設定して間に合うのであれば，それがベスト ユーザーごとなどで( 潜在的に) 無数のキーを管理するのであれば， DB 設計/ 暗号化のタイミングの検討を忘れてはいけない API キーやトークン管理基準を必ず最初にきめる UI 決めやDB の設計など多くの「判断」に影響を与える 不安であればチームで一度読み合わせするなどもいいかも👀 API 仕様はチームで共有（自戒 

みんなで快適なOpen API ライフを！ 

No content