- Amazon.co.jp ・本 (224ページ)
- / ISBN・EAN: 9784873116860
作品紹介・あらすじ
Web APIの設計、開発、運用についての解説書。本書ではAPIをどのように設計し運用すればより効果的なのか、ありがちな罠や落とし穴を避けるにはどういう点に気をつけなければいけないのかを明らかにします。ターゲットは、URIにアクセスするとXMLやJSONなどのデータが返ってくるシンプルなタイプ-XML over HTTP方式やJSON over HTTP方式-のAPIです。
感想・レビュー・書評
-
REST APIの設計を行っているため、読みました。
REST APIのエンドポイントやリクエスト・レスポンスの設計指針、セキュリティの観点から気をつけるべき点など、運用しやすいAPIを設計するための指針が一通り書かれています。
200ページと分量的にも読みやすいです。
世間ではGraphQLが流行っていますが、まだまだREST APIが適しているケースが大半だと思うので、この本を辞書的に活用しつつ運用しやすいAPIを設計していきたいです。詳細をみるコメント0件をすべて表示 -
昔読んだ本
意外と雰囲気でやってることの多いapi設計を体系的に捉え直すことができて役に立った。
今読むには古い内容も多いが、普遍的なところも多いためサーバサイドエンジニアなら一通り目を通しておきたい。 -
まだXMLでのレスポンスが多かった時代の書籍だが、設計思想は今でも十分参考になるものだと感じる。
-
API設計で心がけるべき点が網羅的に記載されている名著。
エンドポイント、レスポンスの構造、HTTP仕様、セキュリティなど様々な内容に触れている。
本書に付属のチェックリストによって、説明されている内容を満たせているかを確認できる。大いに役立つ実用的資料だと思うので、非常にありがたい。
API設計時に読み返すことで、美しい設計を実現する助けになると思う。 -
# APIの教科書.
.
世の中の殆どの人が呼称する `API(Application Programing Interface)` とは、 Web API を指している。.
.
という感じで始まる、割と堅い本。.
.
その起源がどこから始まりなぜ広まったかという歴史的な背景も踏まえながら、HTTPメソッドの厳密な説明や、我々が日々利用している「URL」の秘密まで網羅されている神本。.
.
PUTとPOSTの違いもイマイチ違いがわからず、知らなかった。.
.
API設計の理論的な解説には大変お世話になった。.
.
HTTPメソッドがたった8つしかないのに、なぜこれだけWebの世界が広がったのか。.
.
知っている人も知らない人にも、エンジニアにはおすすめしたい一冊。 . -
実際にまだ触っていない事前学習中なのでイメージしづらい箇所も多々あったが
APIとはこうあるべき、がわかりやすく記載されていた。 -
使いやすく保守しやすいWebAPIを目指して
●感想
他社WebAPIを利用した開発を初めて行うため、手に取った。WebAPIとはなんたるかが、一通り読むとわかる。定期的に読み返したい。
●本書を読みながら気になった記述・コト
> APIのエンドポイントは英語で設計しよう
>「1スクリーン1APIコール、1セーブ1APIコール」という言葉が出てきており、これはひとつの画面を表示するためにコールするのが1つのAPIですむようにおれに合わせたAPIを用意し、何らかのデータをサーバに補zんする場合にも1回のコールですむようにそれに向けの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のレスポンスヘッダを使って書くことができる
・不要な階層は避けること -
WEB APIの設計・開発・運用・保守をしている開発者にとっての必読書。
WEB APIの歴史から、基本的な部分、またどのように設計や開発をしていったらいいのかについて、TwitterやFacebookといった大手企業が提供しているWEB APIを例に挙げ比較しながら説明している。
上記の通り困ったときに立ち戻りたい内容が網羅されているため、常に手元に置いておきたい一冊となっている。 -
Web APIの設計における基本がギュッとまとまっていてよい。
データベースではなく、あくまでアプリケーションなのだ!という視点。