Web APIをなぜつくるのか

Transcript

1. Web APIをなぜ作るのか

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

3. 「データ ユーザー情 記事一覧情 商品詳細情 クーポン情報 Reactを使った動的なアプリケーションの動I

   FD データの取得および表示 不思議な力でどこかから 取ってくる デザイン通り€ 仕様に沿った形式の HTML

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

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

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

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

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

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

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

11. ではどうするのか？

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

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

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

    いけどできる？

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

16. 自宅 社内 もしくは クラウド サーバという名の門番を立てる ユーザーに対する見せ方だけ気にす ればいい 通信に必要な最低限の情報だけサー バに渡せばあとは向こうでよしなに やってくれる

    セキュリティとかビジネスルールの実 現とかの役割を負う ユーザーへの見せ方とかは知らん フロントにデータを投げればあとは よしなに加工してくれるだろう

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

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

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

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

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

22. 自宅 社内 もしくは クラウド バックエンドがすべて を行っていたので、 開発効率を下げないた めにMVCというアーキ テクチャで作ることに なる

    – リクエストを受け付け€ – DBからデータを取ってく€ – データを加工したりするロジックの実X – 加工後のデータを使ってHTMLの作成 リソースくれ HTML

23. 自宅 社内 もしくは クラウド ボタン押した 更新後のHTML ボタンをクリックしたときに「どのURL」に対して「どういうデータ形式」でフォームを送信すればいいか はフレームワークがサポートしているテンプレートエンジンのおかげで気にしなくて良かったりする ~ リクエストを受け付けn

    ~ DBからデータを取ってくn ~ データを加工したりするロジックの実ˆ ~ 加工後のデータを使ってHTMLの作成 ※ テンプレートエンジン → プログラムから渡されたデータを組み込めるHTMLのすごいやつ

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

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

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

    API

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

28. 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

29. 自宅 社内 もしくは クラウド ユーザーデータくれ フロントエンド バックエンド as Web API

    { “name”: mikan, “age”: 28 }

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

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

32. 光あれ

33. 光あれ

34. 人の手で作ってます

35. 要件

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

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

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

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

    Web APIの仕様をどうするか話し合う

40. フロントエンドエンジニア バックエンドエンジニア Web APIの仕様をどうするか話し合う Œ 「〇〇についてのデータが必要なのでエンドポイント を作らないといけないですねd Œ 「返すときは{“name”: string,

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

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

42.  作ろうとしているものについての深い理解（ドメイン理解ž  適当に作るとあとで痛い目にあいまˆ  要件を素直に実装してしまうと既存実装とか次の新規実装との整合性が壊れていく可能性があ  ex.「価格」は果たして素直に「価格」と解釈してしまってよいのかƒ  表示価格・割引価格・会員価格・税抜き・税込み...et`

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

43. APIとはなにか

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

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

46. Notion API (Web API) ‘ Notionのページのあるブロックの 下に子ブロックを追加すe ‘ HTTPリクエスE ‘

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

47. インターフェースとは？

48. インターフェース ↔ 実装 y インターフェースとはユーザーに公開している部w y 関数であれば関数名・引数・返り$ y Web APIであればエンドポイント名、必要なヘッダー情報、

    レスポンスの形x y インターフェースの反対は実T y インターフェースは実装をユーザーから隠すためにある

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

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

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

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

    インターフェース 実装 安定 不安定

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

54. 例えばNotion APIがGo言語で作られていたとして、Go言語向けにしかAPI を公開していないとすると... PHPやJSなど他の言語で作っているアプリからは操作ができない。。 しかし、HTTPをインターフェースとしたREST APIとして作られている場 合... PHPやJSなどどのようなプログラミング言語であってもHTTP通信するた めの基本的な機能は言語機能として、またはライブラリとして用意されて いるので、言語によらず操作可能になる

    インターフェースによって抽象化することの恩恵 インターフェース：呼び出し側の都合を柔軟に受け入れてくれる 実装：実装者の好きにできる

55. Web APIについて

56. 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の設計思想

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

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

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

60. Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA

    7 D6 7 File request handler request handler request handler router リクエスト レスポンス

61. Web API 典型的なWeb APIの動きを説明します Domain Domain Domain Domain Domain DatA

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

62. 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

63. 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 を担当するリクエストハンドラー

64. 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 を担当するリクエストハンドラー

65. 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 を担当するリクエストハンドラー

66. 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 を担当するリクエストハンドラー

67. 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 を担当するリクエストハンドラー

68. 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 を担当するリクエストハンドラー

69. 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がどうにかこうにか描画する
70. None