Tweet
Tweet

Slide 1

Slide 1 text

Web APIをなぜ作るのか

Slide 2

Slide 2 text

以下の疑問を解消することを目標とす9 ( フロントエンドとバックエンドがなぜ存在するの" ( フロントエンドとバックエンドのやりとりのためになぜWeb APIを作る 必要があるのか

Slide 3

Slide 3 text

「データ ユーザー情 記事一覧情 商品詳細情 クーポン情報 Reactを使った動的なアプリケーションの動I FD データの取得および表示 不思議な力でどこかから 取ってくる デザイン通り€ 仕様に沿った形式の HTML

Slide 4

Slide 4 text

「データÇ Ä ユーザー名変えたよ情報 Reactを使った動的なアプリケーションの動5 !A データの送信 不思議な力でどこかに送信する ユーザー名変更

Slide 5

Slide 5 text

「データ É 変更後のユーザー情報 Reactを使った動的なアプリケーションの動4 @ データの送信 不思議な力でどこかから取ってくる 変更後のユーザー詳細画面

Slide 6

Slide 6 text

「どこ」から「どういう力」で 取ってくる？

Slide 7

Slide 7 text

データは「データベース」に保存 されているのでそこから取ってき ます ※ テキストファイルとか動画ファイルとかはS3みたいなストレージに保存されるだろうけどね

Slide 8

Slide 8 text

自宅 社内 もしくは クラウド ??? どうやってデータを取りに行く？ ブラウザおよびReactのプログラムは自宅で動いていますが、データベースは社内またはクラウド という離れた場所においてあります ではどうやってそこにアクセスしたら良いのでしょうか？

Slide 9

Slide 9 text

もし物理的にケーブルで接続できるなら直接データの やりとりも可能だったでしょう。。 しかし今回はそういうわけにはいきません

Slide 10

Slide 10 text

例: さくらインターネット 石狩データセンター クラウド上のデータは最終的にはデータセンターという場所にある大量 のサーバマシンで稼働しています セキュリティも厳重にしてあり普通の人は立ち入ることはできません データセンター内部（Google）

Slide 11

Slide 11 text

ではどうするのか？

Slide 12

Slide 12 text

インターネットを介するしかない

Slide 13

Slide 13 text

自宅 社内 もしくは クラウド

Slide 14

Slide 14 text

自宅 社内 もしくは クラウド データベースに直接アクセスできてしまっていいの？ 他人のデータもみれるんじゃない？ データベース全体を破壊することもできるんじゃない？ 一般ユーザー向けに動くプログラムの中で機密情報 （データベースへのリンクとかパスワード）を取り扱う のでセキュリティ的に相当厳格な実装をしないといけな いけどできる？

Slide 15

Slide 15 text

自宅 社内 もしくは クラウド サーバという名の門番を立てる

Slide 16

Slide 16 text

自宅 社内 もしくは クラウド サーバという名の門番を立てる ユーザーに対する見せ方だけ気にす ればいい 通信に必要な最低限の情報だけサー バに渡せばあとは向こうでよしなに やってくれる セキュリティとかビジネスルールの実 現とかの役割を負う ユーザーへの見せ方とかは知らん フロントにデータを投げればあとは よしなに加工してくれるだろう

Slide 17

Slide 17 text

フロントエンドとバックエンドが必要 な理由はなんとなくわかりましたか？

Slide 18

Slide 18 text

次はフロントエンドとバックエンド がどういうコミュニケーションを 行っているかを説明していきます

Slide 19

Slide 19 text

自宅 社内 もしくは クラウド ？？？ インターネットを介してやり取りするのはわかったけど 具体的にどうやってコミュニケーションしているの？ フロントエンド バックエンド

Slide 20

Slide 20 text

すこしだけ歴史の話 バックエンドとフロントエンドがいま ほどくっきり別れていなかった頃...

Slide 21

Slide 21 text

SPA(Single Page Application)以前のWebアプリケーションはバック エンドがすべての仕事をしていた 自宅 社内 もしくは クラウド リソースくれ HTML

Slide 22

Slide 22 text

自宅 社内 もしくは クラウド バックエンドがすべて を行っていたので、 開発効率を下げないた めにMVCというアーキ テクチャで作ることに なる – リクエストを受け付け€ – DBからデータを取ってく€ – データを加工したりするロジックの実X – 加工後のデータを使ってHTMLの作成 リソースくれ HTML

Slide 23

Slide 23 text

自宅 社内 もしくは クラウド ボタン押した 更新後のHTML ボタンをクリックしたときに「どのURL」に対して「どういうデータ形式」でフォームを送信すればいいか はフレームワークがサポートしているテンプレートエンジンのおかげで気にしなくて良かったりする ~ リクエストを受け付けn ~ DBからデータを取ってくn ~ データを加工したりするロジックの実ˆ ~ 加工後のデータを使ってHTMLの作成 ※ テンプレートエンジン → プログラムから渡されたデータを組み込めるHTMLのすごいやつ

Slide 24

Slide 24 text

SPA以後バックエンドはHTMLを返すのではなく、画面の構成に必要 なデータを渡したりアプリケーションの操作に必要な機能を提供する だけの存在になった → API化されたバックエンド → Web上に作られたAPIなので「Web API」と呼ばれる

Slide 25

Slide 25 text

そうすると今度はフロントエンドとバックエンド間で データ交換するためのルールが必要になる

Slide 26

Slide 26 text

自宅 社内 もしくは クラウド データくれ（HTTPリクエスト） ？？？ フロントエンド バックエンド as Web API

Slide 27

Slide 27 text

現在広く用いられている方式は 「JSON（JavaScript Object Notation）」

Slide 28

Slide 28 text

y 文字p y “Hello Worldb y 数Y y 1, 2, T y 0.1, 1.Q y 真理Y y true/falsd y nult y nult y オブジェク0 y { “key”: “value” H y { “name”: “mikan”, “age”: 28 ! y 配p y [1, 2, 3, “Hello”, true] ↑ これらを自由に組み合わせて作ったものがJSON > JavaScript Object Notation（JSON、ジェイソン） はデータ記述言語の1つである。軽量なテキストベース のデータ交換用フォーマットでありプログラミング言語 を問わず利用できる[1]。名称と構文はJavaScriptにおけ るオブジェクトの表記法に由来する。 JSON

Slide 29

Slide 29 text

自宅 社内 もしくは クラウド ユーザーデータくれ フロントエンド バックエンド as Web API { “name”: mikan, “age”: 28 }

Slide 30

Slide 30 text

フロントエンドから見たときのバックエンドの役割 A HTTPリクエストを受け取ってくれ) A リクエストを処理す) A JSONとしてレスポンスを返す

Slide 31

Slide 31 text

リクエストを送ってそれを処理してくれるのがバッ クエンドっていうのはわかった じゃあその処理してくれる部分って誰がどうやって 作ってるの？

Slide 32

Slide 32 text

光あれ

Slide 33

Slide 33 text

光あれ

Slide 34

Slide 34 text

人の手で作ってます

Slide 35

Slide 35 text

要件

Slide 36

Slide 36 text

要件 デザイナー 要件に沿った画面を描く

Slide 37

Slide 37 text

要件 デザイナー フロントエンドエンジニア 要件に沿った画面を描く デザインを見ながら画面を実装する 要件にそってインタラクションとか振る舞い をどうするか考える

Slide 38

Slide 38 text

要件 デザイナー フロントエンドエンジニア バックエンドエンジニア 要件に沿った画面を描く デザインを見ながら画面を実装する 要件にそってインタラクションとか振る舞い をどうするか考える 要件に沿ったデータの持ち方とかバックエン ドで実装すべきロジックをどうするか考える

Slide 39

Slide 39 text

要件 デザイナー フロントエンドエンジニア バックエンドエンジニア 要件に沿った画面を描く デザインを見ながら画面を実装する 要件にそってインタラクションとか振る舞い をどうするか考える 要件に沿ったデータの持ち方とかバックエン ドで実装すべきロジックをどうするか考える Web APIの仕様をどうするか話し合う

Slide 40

Slide 40 text

フロントエンドエンジニア バックエンドエンジニア Web APIの仕様をどうするか話し合う Œ 「〇〇についてのデータが必要なのでエンドポイント を作らないといけないですねd Œ 「返すときは{“name”: string, “age”: number}って いう形にしてほしいですd Œ 「エラーしたときはどうする？d Œ 「△△のデータについて仕様変更があって□□ってい う情報を追加してほしいですd Œ 「◎◎っていうデータってどこからもってきたらいい ですかね？d Œ 「それならエンドポイントAから取れるよd Œ 「なるほど。エンドポイントAにアクセスするため には▲▲のIDが必要で、それはエンドポイントBを から取れて、エンドポイントBにアクセスするため には◆◆っていう文字列が必要でここはユーザー データがあれば取ってこれるからd Œ 「◆◆→エンドポイントB→▲▲→エンドポイント Aっていうフローを書けば取ってこれるな」

Slide 41

Slide 41 text

ソフトウェアの設計に求められる(と僕が思ってる)スキル

Slide 42

Slide 42 text

 作ろうとしているものについての深い理解（ドメイン理解ž  適当に作るとあとで痛い目にあいまˆ  要件を素直に実装してしまうと既存実装とか次の新規実装との整合性が壊れていく可能性があ  ex.「価格」は果たして素直に「価格」と解釈してしまってよいのかƒ  表示価格・割引価格・会員価格・税抜き・税込み...et`  要件を咀嚼してソフトウェアとして実装可能なものに再解釈する必要がありまˆ  画面に関する設½  画面に必要な情報の設½  画面で発生するアクションとそれによる状態変i  状態の不整合を発生させないための不変条件の整´  APIに関する設½  既存のAPIにフィールド追加する vs. 新しいAPIを作る をきちんと判断す  フロントにとってもバックにとっても辛くないAPIを設計す  安全š  パフォーマン  オーバーフェッチング/アンダーフェッチンP  n+1問s  時には作らないことを決断する意È  作れば作るほどデータもロジックも画面もこんがらがっていくのでどんどん作りにくくなりまˆ  不要なものは作らないほうが時には懸命でˆ  「システムを一番速くてコストダウンも出来る方法は超絶技巧のプログラミングではなく、ビジネスロジックを 単純にすること。」

Slide 43

Slide 43 text

APIとはなにか

Slide 44

Slide 44 text

API = Application Programming Interface ソフトウェアやライブラリ、サービスなどがそれを操作するためにユーザーに公開している関数や らクラスやらエンドポイントやら

Slide 45

Slide 45 text

fetch API (JS) D リソース取得のためのAP0 D HTTP通信に使$ D fetchという名前の関数

Slide 46

Slide 46 text

Notion API (Web API) ‘ Notionのページのあるブロックの 下に子ブロックを追加すe ‘ HTTPリクエスE ‘ PATCHリクエスE ‘ ヘッダー：通信を行うために必要 な情報を格納する場d ‘ Authorizatiow ‘ 認証情6 ‘ Content-Typ$ ‘ リクエストデータがjsonで あることを表W ‘ Notion-Versiow ‘ Notion APIのバージョン

Slide 47

Slide 47 text

インターフェースとは？

Slide 48

Slide 48 text

インターフェース ↔ 実装 y インターフェースとはユーザーに公開している部w y 関数であれば関数名・引数・返り$ y Web APIであればエンドポイント名、必要なヘッダー情報、 レスポンスの形x y インターフェースの反対は実T y インターフェースは実装をユーザーから隠すためにある

Slide 49

Slide 49 text

インターフェース ↔ 実装 インターフェース 実装 Input Output

Slide 50

Slide 50 text

なぜ実装をユーザーから隠す必要が あるのか

Slide 51

Slide 51 text

安定な挙動だけをユーザーに届ける ため

Slide 52

Slide 52 text

なぜ実装をユーザーから隠す必要があるのか – 1度ユーザーに公開した部分は滅多なことでは変更できなくなi – なぜならユーザーからしたら、今日利用できている機能が明日にはパラメータが変わって使 えなくなるなんて状況は許容できな7 – しかし開発は継続的に行われているので実装は常に変化していi – そうした安定な部分と不安定な部分を分けるための仕組みがインターフェースです インターフェース 実装 安定 不安定

Slide 53

Slide 53 text

インターフェース = 抽象化

Slide 54

Slide 54 text

例えばNotion APIがGo言語で作られていたとして、Go言語向けにしかAPI を公開していないとすると... PHPやJSなど他の言語で作っているアプリからは操作ができない。。 しかし、HTTPをインターフェースとしたREST APIとして作られている場 合... PHPやJSなどどのようなプログラミング言語であってもHTTP通信するた めの基本的な機能は言語機能として、またはライブラリとして用意されて いるので、言語によらず操作可能になる インターフェースによって抽象化することの恩恵 インターフェース：呼び出し側の都合を柔軟に受け入れてくれる 実装：実装者の好きにできる

Slide 55

Slide 55 text

Web APIについて

Slide 56

Slide 56 text

Web APIとは Web APIのなかでもとくにREST APIについて説明する REST AP— • HTTPをインターフェースとしたAP— • HTTPリクエスe • ur… • ヘッダ‡ • メソッW • GET、POST、PATCH、DELETr • ボデQ • json、form-dati • HTTPレスポン‘ • ステータスコーW • 200、404、503..E • ヘッダ‡ • ボデQ • text、json、video、image ※REST以外のWeb APIの© • RPÈ • SOA¼ • XM³ • 超複Ÿ • GraphQ³ • BFF(Backend For Frontend)でよく使われ— • オーバーフェッチング・アンダーフェッチング・ N+1問題を解決するために登場し¶ • gRPÈ • Protocol Buffe™ • マイクロサービス間の通信に用いられる REST: Web APIの設計思想

Slide 57

Slide 57 text

Web APIとは HTTPという方式を使ってネットワーク越しに呼び出せるようになったAPI Webアプリケーションとは誤解を恐れずに言うな8 バックエンドをJSON生成% フロントエンドをJSON色付け係 として作ったアプリ

Slide 58

Slide 58 text

リクエスト データアクセス データ レスポンス（JSON） Webアプリケーションのクソ雑概略図

Slide 59

Slide 59 text

Web APIはどういう作りを しているのか

Slide 60

Slide 60 text

Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA 7 D6 7 File request handler request handler request handler router リクエスト レスポンス

Slide 61

Slide 61 text

Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA 7 D6 7 File request handler request handler request handler router リクエスト レスポンス リクエストを適切なハンド ラーに仲介してくれるやつ 特定のリクエストを処理す る役目を負ったやつ ビジネスロジックを実行 する場所 データの保存場所

Slide 62

Slide 62 text

Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA 7 D6 7 File request handler request handler request handler router リクエスト http://localhost:3000/api/todos GET

Slide 63

Slide 63 text

Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA 7 D6 7 File request handler request handler request handler router リクエスト http://localhost:3000/api/todos GET GET, /api/todos を担当するリクエストハンドラー

Slide 64

Slide 64 text

Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA 7 D6 7 File request handler request handler request handler router リクエスト http://localhost:3000/api/todos GET GET, /api/todos を担当するリクエストハンドラー

Slide 65

Slide 65 text

Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA 7 D6 7 File request handler request handler request handler router リクエスト http://localhost:3000/api/todos GET GET, /api/todos を担当するリクエストハンドラー

Slide 66

Slide 66 text

Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA 7 D6 7 File request handler request handler request handler router リクエスト http://localhost:3000/api/todos GET GET, /api/todos を担当するリクエストハンドラー

Slide 67

Slide 67 text

Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA 7 D6 7 File request handler request handler request handler router リクエスト http://localhost:3000/api/todos GET GET, /api/todos を担当するリクエストハンドラー

Slide 68

Slide 68 text

Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA 7 D6 7 File request handler request handler request handler router リクエスト http://localhost:3000/api/todos GET GET, /api/todos を担当するリクエストハンドラー

Slide 69

Slide 69 text

Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA 7 D6 7 File request handler request handler request handler router リクエスト http://localhost:3000/api/todos GET GET, /api/todos を担当するリクエストハンドラー レスポンス [ {“id”: 1, “title”: “TODO1”, “createdAt”: “2024-01-01 12:00:00”}, {“id”: 2, “title”: “TODO2”, “createdAt”: “2024-01-01 13:15:00”} ] → 受け取ったJSONをもとにReactがどうにかこうにか描画する

Slide 70

Slide 70 text

No content