APIについて

Transcript

1. API について 気ままに勉強会 #14
2. 今日の目標 API を理解しよう
3. アジェンダ API とは REST API とは API のセキュリティ Power Automate での API
4. Miyake Mito https://www.icsoft.jp/ @MiTo60448639 https://qiita.com/MiyakeMito
5. Power Automate と Power Virtual Agents で ゲームを作ってます ⚫ オセロ ⚫ 神経衰弱 ⚫ どうぶつしょうぎ ⚫ WORDL
6. 本日の参考サイト ▪ Microsoft Graph APIってなに？(りなたむさん) https://speakerdeck.com/rnakamuramartiny/microsoft-graphtutenani ▪ Yahoo! デベロッパーネットワーク https://developer.yahoo.co.jp/ ▪ 【連載】世界一わかりみの深いOAuth入門 〜 その1:OAuthってなに？ 〜 https://tech-lab.sios.jp/archives/25470
7. API とは
8. APIとは ① ◼ 「Application Programming Interface」 ◼ 「アプリケーション」と「プラグラム」を「つなぐ」もの ◼ 異なるアプリやソフトウェアが、APIを通じて外部のアプリ やソフトウェアを呼び出し、その機能を利用する仕組み API API提供者 API利用者 WEBサービスを普及 サービスの流通 利便性・生産性向上 開発の効率化 セキュリティ向上 ソフトウェアの機能を 共有できる仕組み
9. APIとは ② API API API API API API API API API みんなAPIでつながる
10. APIとは ③ ◼ Web 上で API のやり取りを可能としたもの ⇒ Web API ◼ Web API のメリット • ネットワークがつながればどこからでもアクセスができる • ネットワークがつながれば何からでもアクセスができる • やりとりする情報の取り扱いが容易である
11. ◼ Yahoo！商品検索 API • JANコード（バーコード）で、Yahoo!ショッピングの商品検 索結果を取得してみます • 事前にアプリケーションIDを登録する必要があります https://developer.yahoo.co.jp/yconnect/v1/registration.html • ブラウザからアクセスします https://shopping.yahooapis.jp/ShoppingWebService/V3/itemSearch?appid =<アプリケーションID>&jan_code=<JANコード>&in_stock=true ここでちょこっとデモ
12. APIとは ④ ◼ 各サービスが異なるルールでAPIを作ってしまうと、 つながるものもつながらない ➢ RESTと呼ばれる設計原則に従って作る それが REST API（RESTful API）
13. REST API とは
14. REST APIとは ① ▪ 「REpresentational State Transfer」 具象的な 状態の 転送 ▪ 「具体的に状態を定義した情報の転送」 ▪ 「RESTの４原則」を満たす「RESTful」なAPI
15. RESTの４原則 1. 統一インターフェース 2. アドレス可能性 3. 接続性 4. ステートレス性
16. 統一インターフェース (Uniform Interface) ▪ あらかじめ定義し共有された方法でやり取りすること ① リクエスト ② レスポンス JSONとXML形式で返すこと (最近はJSONのみ返すシステムが多い） HTTPメソッド 操作 GET 取得 POST 作成 PUT 更新 DELETE 削除
17. HTTPリクエストの構成 ▪ メソッド以外にも指定する要素があります POST https://jlp.yahooapis.jp/FuriganaService/V2/furigana ?APPID=<AppID> Content-Type: application/json { "id": "1234-1", "jsonrpc": "2.0", "method": "jlp.furiganaservice.furigana", "params": { “q”: “愛くるしいパンダが一杯登場する登壇", "grade": 1 } } メソッド パスパラメータ ルビ振り クエリパラメータ リクエストヘッダ リクエストボディ リクエスト ライン
18. HTTPレスポンスの構成 ▪ レスポンスにも構成があります 200 OK DATE: Thu, 14 Apr 2022 13:21:16 GMT Content-Type: application/json; charset=utf-8 { "id": "1234-1", "jsonrpc": "2.0", "result": { "word": [ { "furigana": "あいくるしい", "roman": "aikurusii", "subword": [ ルビ振り レスポンスヘッダ レスポンスボディ ステータス
19. HTTPメソッド GET ▪ リソース（情報）を取得する ▪ Webサイトをブラウザーで見るとき、内部ではGETによるリク エストが行われている たけのこは何個買えばいい？ 12コだよ API 買い物リスト たけのこ 12コ 天然水 8ℓ Panxa
20. HTTPメソッド POST ▪ リソース（情報）を新規作成する ▪ GETはパラメーターをURI中に含むが、POSTはリクエストボ ディーに配置するため、パラメーターの長さに上限がない ▪ べき等（何度リクエストしても同じ結果となる）の性質を持た ない リンゴ10コを追加したよ API 買い物リストにリンゴを10コ追加して Panxa 買い物リスト たけのこ 12コ 天然水 8ℓ りんご 10コ
21. HTTPメソッド PUT ▪ リソース（情報）を更新する ▪ POSTでリソースを新規作成し、PUTで更新するのがWeb API の典型 リンゴ10コを、笹10トンに変更しました API まちがえた、リンゴじゃなくて笹10トンです Panxa 買い物リスト たけのこ 12コ 天然水 8ℓ 笹 10トン
22. HTTPメソッド PATCH ▪ リソース（情報）を部分更新する ▪ PUTはすべて更新し、PATCHは一部更新する まちがえたｗｗ 笹10トンてｗｗｗ 笹は10キロっすｗｗｗｗ デスヨネーｗｗ 笹を10キロに変更しました API Panxa 買い物リスト たけのこ 12コ 天然水 8ℓ 笹 10トン→10キロ
23. HTTPメソッド DELETE ▪ リソース（情報）を削除する ▪ URIが指し示すリソースが存在しない場合でもエラーにならず、 「既に削除されている」ことを返すのが理想的（個人的見解） やっぱ笹イラネｗｗｗ 飽きたｗｗｗ 買い物リストから、笹を削除しましたけど 明日から何を食べるの？ API Panxa 買い物リスト たけのこ 12コ 天然水 8ℓ － －
24. HTTPメソッド まとめ メソッド CRUD 動作 リクエスト ボディ べき等 GET READ リソースから情報を取得 なし 〇 POST CREATE リソース名がサーバ側で割り振られて作成 あり × PUT CREATE/ UPDATE リソース名を指定して作成または更新 （REPLACE） あり 〇 PATCH UPDATE リソースを部分更新する あり 〇 DELETE DELETE リソースを削除 なし 〇 ※あくまでAPI設計の指標です。これらに当てはまらないAPIも存在します。
25. アドレス可能性 (Addressability) ▪ すべての情報が一意なURIを持っていて、提供する情報 をURIで表現できること https://graph.microsoft.com/ https://shopping.yahooapis.jp/ https://jlp.yahooapis.jp/ etc. https://api.line.me/
26. 接続性 (Connectability) ▪ 応答する情報にハイパーリンクを含むことができる ▪ １つのリンクから別の情報に接続が可能であること "results": [ { "name": "Luke Skywalker", "height": "172", "mass": "77", "hair_color": "blond", "skin_color": "fair", "eye_color": "blue", "birth_year": "19BBY", "gender": "male", "homeworld": "https://swapi.dev/api/planets/1/", "films": [ "https://swapi.dev/api/films/1/", "https://swapi.dev/api/films/2/", "https://swapi.dev/api/films/3/", "https://swapi.dev/api/films/6/" ], "species": [], Luke Skywalker が登場する作品 の情報が記載されている
27. ▪ Stateless=「状態がない」「やりとりが１回ごとに完結する」 ▪ 前のやり取りの結果を引き継がない ステートレス性 (Stateless) API ◦◦の情報をちょうだい ▲▲になります さっきの情報をもう一度ちょうだい さっきの情報がもう何だかわからないよ
28. APIのセキュリティ
29. APIの危険性 外部サービスと接続し、データを転送するという性質上 APIが破損、公開、ハッキングされると 大規模なデータ侵害が発生します
30. 認可サーバー APIのセキュリティ ▪ OAuth2.0 ① 許可申請 クライアント ② 権限付与確認 ③ 許可 ④ 認可コード発行 利用権でアクセス ⑤ アクセストークン リクエスト ⑥ アクセストークン 取得 そうだよ リソースサーバの API使いたい ID Pass 知ってるクライアント？ 許可されたよ 許可権を利用権 にかえて 利用権だよ ⑦ APIへ アクセス ⑧ リソース取得 やったぜ！ リソースオーナー リソースサーバー リソースサーバーの ID・パスワード API
31. OAuth2.0 ▪ 従来のID・パスワードとは異なるトークンベースの認証 – ID・パスワードを他のサービス渡さず済む ▪ 委譲する権限を限定（認可） – トークンを盗まれても被害を最小限に抑えれられる ▪ アクセストークンに有効期限を設定 – 万が一トークンを盗まれても有効期限過ぎると使えない ▪ 認可コードフローなどによりトークンを安全に取得 – ユーザーの質が担保できる
32. Power Automate でのAPI
33. Power AutomateでAPI 提供されるコネクタ コネクタを共有 １. 提供コネクタを利用 ２. カスタムコネクタを利用 ３. HTTPアクション ある Power Automateで外部サービスを呼びたい 共有する ない 共有しない
34. 提供コネクタ ▪ 標準コネクタ＋プレミアムコネクタ ▪ Services :697 Actions :8686 Triggers :894 （2022/4/15) ▪ https://connectorinfo.z31.web.core.windows.net/apilist.html ▪ https://docs.microsoft.com/ja-jp/connectors/connector- reference/
35. カスタムコネクタ ▪ コネクターが用意されていないサービスとは、カスタム コネクター を構築することで通信が可能 ▪ 作成したカスタムコネクタは組織内で共有 することができる ▪ Microsoft に認証され公開することも可能
36. HTTPアクション ▪ HTTPアクションによるAPI連携が可能 ▪ Power AutomateからHTTPリクエストする際に利用 ▪ 認証オプション – 基本（HTTP認証） – クライアント証明書 – Active Directory Oauth – Raw（未加工）
37. HTTP要求アクション ▪ APIの作成も可能です – [HTTP要求の受信時]でリクエストを受け取り、 [応答]でレスポンスします – エンドポイントの URL には、共有アクセス署名 (SAS) を含みます – 受信にHTMLメソッドを指定可能です
38. まとめ APIは便利です 上手く利用して 便利なフローを作ろう！
39. ありがとうございました