API について 気ままに勉強会 #14

今日の目標 API を理解しよう

アジェンダ API とは REST API とは API のセキュリティ Power Automate での API

Miyake Mito https://www.icsoft.jp/ @MiTo60448639 https://qiita.com/MiyakeMito

Power Automate と Power Virtual Agents で ゲームを作ってます ⚫ オセロ ⚫ 神経衰弱 ⚫ どうぶつしょうぎ ⚫ WORDL

本日の参考サイト ■ 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

API とは

APIとは ① ◼ 「Application Programming Interface」 ◼ 「アプリケーション」と「プラグラム」を「つなぐ」もの ◼ 異なるアプリやソフトウェアが、APIを通じて外部のアプリ やソフトウェアを呼び出し、その機能を利用する仕組み API API提供者 API利用者 WEBサービスを普及 サービスの流通 利便性・生産性向上 開発の効率化 セキュリティ向上 ソフトウェアの機能を 共有できる仕組み

APIとは ② API API API API API API API API API みんなAPIでつながる

APIとは ③ ◼ Web 上で API のやり取りを可能としたもの ⇒ Web API ◼ Web API のメリット • ネットワークがつながればどこからでもアクセスができる • ネットワークがつながれば何からでもアクセスができる • やりとりする情報の取り扱いが容易である

◼ 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=&in_stock=true ここでちょこっとデモ

APIとは ④ ◼ 各サービスが異なるルールでAPIを作ってしまうと、 つながるものもつながらない ➢ RESTと呼ばれる設計原則に従って作る それが REST API（RESTful API）

REST API とは

REST APIとは ① ■ 「REpresentational State Transfer」 具象的な 状態の 転送 ■ 「具体的に状態を定義した情報の転送」 ■ 「RESTの４原則」を満たす「RESTful」なAPI

RESTの４原則 1. 統一インターフェース 2. アドレス可能性 3. 接続性 4. ステートレス性

統一インターフェース (Uniform Interface) ■ あらかじめ定義し共有された方法でやり取りすること ① リクエスト ② レスポンス JSONとXML形式で返すこと (最近はJSONのみ返すシステムが多い） HTTPメソッド 操作 GET 取得 POST 作成 PUT 更新 DELETE 削除

HTTPリクエストの構成 ■ メソッド以外にも指定する要素があります POST https://jlp.yahooapis.jp/FuriganaService/V2/furigana ?APPID= Content-Type: application/json { "id": "1234-1", "jsonrpc": "2.0", "method": "jlp.furiganaservice.furigana", "params": { “q”: “愛くるしいパンダが一杯登場する登壇", "grade": 1 } } メソッド パスパラメータ ルビ振り クエリパラメータ リクエストヘッダ リクエストボディ リクエスト ライン

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": [ ルビ振り レスポンスヘッダ レスポンスボディ ステータス

HTTPメソッド GET ■ リソース（情報）を取得する ■ Webサイトをブラウザーで見るとき、内部ではGETによるリク エストが行われている たけのこは何個買えばいい？ 12コだよ API 買い物リスト たけのこ 12コ 天然水 8ℓ Panxa

HTTPメソッド POST ■ リソース（情報）を新規作成する ■ GETはパラメーターをURI中に含むが、POSTはリクエストボ ディーに配置するため、パラメーターの長さに上限がない ■ べき等（何度リクエストしても同じ結果となる）の性質を持た ない リンゴ10コを追加したよ API 買い物リストにリンゴを10コ追加して Panxa 買い物リスト たけのこ 12コ 天然水 8ℓ りんご 10コ

HTTPメソッド PUT ■ リソース（情報）を更新する ■ POSTでリソースを新規作成し、PUTで更新するのがWeb API の典型 リンゴ10コを、笹10トンに変更しました API まちがえた、リンゴじゃなくて笹10トンです Panxa 買い物リスト たけのこ 12コ 天然水 8ℓ 笹 10トン

HTTPメソッド PATCH ■ リソース（情報）を部分更新する ■ PUTはすべて更新し、PATCHは一部更新する まちがえたｗｗ 笹10トンてｗｗｗ 笹は10キロっすｗｗｗｗ デスヨネーｗｗ 笹を10キロに変更しました API Panxa 買い物リスト たけのこ 12コ 天然水 8ℓ 笹 10トン→10キロ

HTTPメソッド DELETE ■ リソース（情報）を削除する ■ URIが指し示すリソースが存在しない場合でもエラーにならず、 「既に削除されている」ことを返すのが理想的（個人的見解） やっぱ笹イラネｗｗｗ 飽きたｗｗｗ 買い物リストから、笹を削除しましたけど 明日から何を食べるの？ API Panxa 買い物リスト たけのこ 12コ 天然水 8ℓ － －

HTTPメソッド まとめ メソッド CRUD 動作 リクエスト ボディ べき等 GET READ リソースから情報を取得 なし 〇 POST CREATE リソース名がサーバ側で割り振られて作成 あり × PUT CREATE/ UPDATE リソース名を指定して作成または更新 （REPLACE） あり 〇 PATCH UPDATE リソースを部分更新する あり 〇 DELETE DELETE リソースを削除 なし 〇 ※あくまでAPI設計の指標です。これらに当てはまらないAPIも存在します。

アドレス可能性 (Addressability) ■ すべての情報が一意なURIを持っていて、提供する情報 をURIで表現できること https://graph.microsoft.com/ https://shopping.yahooapis.jp/ https://jlp.yahooapis.jp/ etc. https://api.line.me/

接続性 (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 が登場する作品 の情報が記載されている

■ Stateless=「状態がない」「やりとりが１回ごとに完結する」 ■ 前のやり取りの結果を引き継がない ステートレス性 (Stateless) API ○○の情報をちょうだい ▲▲になります さっきの情報をもう一度ちょうだい さっきの情報がもう何だかわからないよ

APIのセキュリティ

APIの危険性 外部サービスと接続し、データを転送するという性質上 APIが破損、公開、ハッキングされると 大規模なデータ侵害が発生します

認可サーバー APIのセキュリティ ■ OAuth2.0 ① 許可申請 クライアント ② 権限付与確認 ③ 許可 ④ 認可コード発行 利用権でアクセス ⑤ アクセストークン リクエスト ⑥ アクセストークン 取得 そうだよ リソースサーバの API使いたい ID Pass 知ってるクライアント？ 許可されたよ 許可権を利用権 にかえて 利用権だよ ⑦ APIへ アクセス ⑧ リソース取得 やったぜ！ リソースオーナー リソースサーバー リソースサーバーの ID・パスワード API

OAuth2.0 ■ 従来のID・パスワードとは異なるトークンベースの認証 – ID・パスワードを他のサービス渡さず済む ■ 委譲する権限を限定（認可） – トークンを盗まれても被害を最小限に抑えれられる ■ アクセストークンに有効期限を設定 – 万が一トークンを盗まれても有効期限過ぎると使えない ■ 認可コードフローなどによりトークンを安全に取得 – ユーザーの質が担保できる

Power Automate でのAPI

Power AutomateでAPI 提供されるコネクタ コネクタを共有 １. 提供コネクタを利用 ２. カスタムコネクタを利用 ３. HTTPアクション ある Power Automateで外部サービスを呼びたい 共有する ない 共有しない

提供コネクタ ■ 標準コネクタ＋プレミアムコネクタ ■ 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/

カスタムコネクタ ■ コネクターが用意されていないサービスとは、カスタム コネクター を構築することで通信が可能 ■ 作成したカスタムコネクタは組織内で共有 することができる ■ Microsoft に認証され公開することも可能

HTTPアクション ■ HTTPアクションによるAPI連携が可能 ■ Power AutomateからHTTPリクエストする際に利用 ■ 認証オプション – 基本（HTTP認証） – クライアント証明書 – Active Directory Oauth – Raw（未加工）

HTTP要求アクション ■ APIの作成も可能です – [HTTP要求の受信時]でリクエストを受け取り、 [応答]でレスポンスします – エンドポイントの URL には、共有アクセス署名 (SAS) を含みます – 受信にHTMLメソッドを指定可能です

まとめ APIは便利です 上手く利用して 便利なフローを作ろう！

ありがとうございました