Web API The Good Parts の商品レビュー

水野貴明(著者)

2024/11/10

- グローバルスタンダード
- RFC

これらに準拠するのがAPIを設計するにあたっては、利用者にやさしく使いやすいものに繋がるのだろう

最後にチェックリストの付録もあり、実際にPublicなAPIを設計する際には見返すと良さそう

2024/06/08

こちらはWebAPIを実現し、一般公開していくために、あるべき形を守るために、必要となるルール、セキュリティなどを学ぶのに適していそう。
114冊目読了。

2024/01/30

API設計で心がけるべき点が網羅的に記載されている名著。
エンドポイント、レスポンスの構造、HTTP仕様、セキュリティなど様々な内容に触れている。
本書に付属のチェックリストによって、説明されている内容を満たせているかを確認できる。大いに役立つ実用的資料だと思うので、非常にありがたい。
API設計時に読み返すことで、美しい設計を実現する助けになると思う。

2023/10/14

# APIの教科書.
.
世の中の殆どの人が呼称する `API(Application Programing Interface)` とは、 Web API を指している。.
.
という感じで始まる、割と堅い本。.
.
その起源がどこから始まりなぜ広まったかという歴史的な背景も踏まえながら、HTTPメソッドの厳密な説明や、我々が日々利用している「URL」の秘密まで網羅されている神本。.
.
PUTとPOSTの違いもイマイチ違いがわからず、知らなかった。.
.
API設計の理論的な解説には大変お世話になった。.
.
HTTPメソッドがたった8つしかないのに、なぜこれだけWebの世界が広がったのか。.
.
知っている人も知らない人にも、エンジニアにはおすすめしたい一冊。 .

2023/02/28

実際にまだ触っていない事前学習中なのでイメージしづらい箇所も多々あったが
APIとはこうあるべき、がわかりやすく記載されていた。

2023/01/09

使いやすく保守しやすいWebAPIを目指して

●感想
　他社WebAPIを利用した開発を初めて行うため、手に取った。WebAPIとはなんたるかが、一通り読むとわかる。定期的に読み返したい。

●本書を読みながら気になった記述・コト
> APIのエンドポイントは英語で設計しよう

>「1スクリーン1APIコール、1セーブ1APIコール」という言葉が出てきており、これはひとつの画面を表示するためにコールするのが１つのAPIですむようにおれに合わせたAPIを用意し、何らかのデータをサーバに補zんする場合にも１回のコールですむようにそれに向けのAPIを用意するのがよい、ということが述べられています

>Martin fowler氏による「2010年にREST APIの設計レベルについての記事」によれば、すばらしいREST APIにいたるための設計レベルには以下のようなものがあります
・LEVEL0 - HTTPを使ってる
・LEVEL1 - リソースの概念の導入
・LEVEL2 - HTTP の動詞（GET/POST/PUT/DELETE など）の導入
・LEVEL3 - HATEOASの概念の導入

・HATEOAS...hypermedia as the engine of application state という概念
　> HATEOAS はAPIの返すデータの中に、次に行う行動、取得するデータ等のURINEをリンクとして含めることで、そのデータを見れば次にどのエンドポイントにアクセスすればよいかがわかるような設計です。たとえばSNSの返す友達一覧のデータがあったとすると、その友達のそれぞれのデータにはそのユーザーのリソースを取得するためのリンクが含まれています

> Aceptリクエストヘッダにはメディアタイプを複数指定できるため、複数指定されている場合には、戦闘に指定されているものから順に見ていって、最初に出てくるサポートしているデータ形式で返す、といったことができます
>これらのうちのどれを使うについては、かなり好みの問題といえます。
>拡張子を扱う方法はあまり現在では使われていません。この方法は、かつてTwitterなどでも使われていた方法ですし、わかりやすい方法だとは思います
>筆者としては1つだけを選ぶならURIでクエリパラメータを使う方法を、複数選ぶならメディアタイプをヘッダで指定する方法とクエリパラメータを使う方法を両方サポートする、というのをおすすめします
>URIだけで指定できるほうが手軽であり見た目にもわかりやすく、さらに初心者にやさしい方法であるからです

＊レスポンスデータ設計の際、できるかぎりエンベロープの利用を避ける
・HTTPにはヘッダの概念があり、そこにさまざまなデータを入れることができる。エラーかどうかの判別もステータスコードをきちんと返すことで行うことができる
・header内に書かれていたようなメタ情報は、HTTPの仕様に則ってHTTPのレスポンスヘッダを使って書くことができる
・不要な階層は避けること

2022/11/30

■ひとことで言うと？
利用者の用途に則しつつ、変更・管理もしやすいAPIは美しい

■キーポイント
- 美しいAPI
- 「使いやすい」「変更しやすい」「頑強・セキュアである」
- API設計の大原則
- ユーザーの利用用途を想定して設計すること
- エンドポイント（URI）：覚えやすい、APIの機能がわかる
- レスポンス：PGで処理しやすい、必要十分な情報が入っている
- API設計時の考慮事項
- 変更管理：APIを変更しやすくする
- URI中にAPIのメジャーバージョン情報を含める
- セキュリティ：安全な通信や不正なコードの実行防止対策を行う
- 通信のHTTPS化、独自ヘッダの追加と検証、JS解釈できないJSONレスポンスなど
- 過剰アクセス防止：意図しない過剰アクセスに対処する
- APIの用途に応じたレートリミットの設定

2022/10/07

WEB APIの設計・開発・運用・保守をしている開発者にとっての必読書。
WEB APIの歴史から、基本的な部分、またどのように設計や開発をしていったらいいのかについて、TwitterやFacebookといった大手企業が提供しているWEB APIを例に挙げ比較しながら説明している。
上記の通り困ったときに立ち戻りたい内容が網羅されているため、常に手元に置いておきたい一冊となっている。

2022/06/18

Web APIの設計における基本がギュッとまとまっていてよい。
データベースではなく、あくまでアプリケーションなのだ！という視点。

2022/05/04

2014年の本なので、技術面の解説はけっこう古くなっている(たとえばIEのバージョンについてはIEをサポートしない選択ができる)ものの考え方の面は古くなっていない。根幹をなす思想は2つで、

仕様が決まっているものは仕様に従う

仕様が存在していないものはデファクトスタンダードに従う

ということに帰着する。APIは Hackable = ドキュメントを首っ引きで読まなくても使えるようにせよ、というのは金言だろう。2022年に読んで新しい知見をたくさん得られるものではないが、サクッと読めるのでチームで認識を合わせるのには使えそうな感じはする。