Web API: The Good Parts

著者 :
  • オライリージャパン
4.23
  • (57)
  • (63)
  • (19)
  • (1)
  • (1)
本棚登録 : 976
感想 : 53
本ページはアフィリエイトプログラムによる収益を得ています
  • 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を設計していきたいです。

  • 昔読んだ本

    意外と雰囲気でやってることの多い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のレスポンスヘッダを使って書くことができる
    ・不要な階層は避けること

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

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

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

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

全53件中 1 - 10件を表示

著者プロフィール

ソフトウェア開発者/技術投資家。Baidu、DeNAなどでソフトウエア開発やマネジメントを経験したのち、現在は英AI企業Nexus FrontierTechのCTO/Co-Founderとして、多国籍開発チームを率いている。また、その傍ら、スタートアップを中心に開発支援や開発チーム構築などの支援や、書籍の執筆、翻訳なども行っている。

「2023年 『プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ』 で使われていた紹介文から引用しています。」

水野貴明の作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
エリック・リース
有効な右矢印 無効な右矢印
  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×