l

o

a

d

i

n

g

.

.

.

[技術書籍レビュー] APIデザイン・パターン

2026/04/02

レビュー

t f B! P L
eyecatch WebエンジニアにとってAPIって切っても切り離せない、腐れ縁カップルなんですよ。 RestfulAPIから、簡易なバッチシステムまで、世の中にはいろいろなAPIがあり、星の数ほどのフレームワークが存在します。(オレオレFW含む) そして、プログラミングのデザインパターンを理解した直後ということもあり、APIのデザイン・パターンもついでに学習してしまおうと、 今更ながら書籍を手に取ってみました。

レビュー

★★☆☆☆
正直言って、あまり学習にはならなかったな〜という読後感です。 それ以外に、この書籍は、Kindleで購入したんですが、scanしただけの書籍なので、kindleでの紙スキャンだけ書籍は基本的にどんなにいい内容であったとしても、星が下がってしまいます。 売り手の安直感が拭えません・・・ さらに、誤字脱字が、この書籍は頻繁にあるため、読んでいてそういう箇所が気になって仕方がなかったんですよね。 なので、内容があまり入ってこないというのも星の低さの原因でした。 もっと突っ込んで言うとすると、翻訳も古い翻訳システムでも使ったのかと言うぐらい、日本語でワザとわかりにくく書いているのか?と疑いたくなるぐらいの読みづらさ・・・ コンテンツクリエイティビリティの低さがどうしても気になってしまったんですね。 肝心のAPIデザインパターンはというと、もちろん学びになる点はありはしましたが、かなり局所的な事が長々と指摘されていたため、個人的には肌感が合わないという感覚が終始抜けませんでした。

この書籍で学べるポイント

リソース思考API

コンピュータに対して、サブルーチンやメソッドを呼び出すスタイルを、RPC(リモートプロシージャコール)と呼びます。 ライブラリ関数である、プロシージャをコール(呼び出し)する、この処理は、全てのAPIには向かないそうです。 飛行機チケット処理のAPIを例にとると、
・フライトの情報表示 ・フライト予約 ・予約のキャンセル ・予約の変更 ・オプションの追加
これらを、それぞれのAPIの関数でアクセスさせるよりも、 「FlightReservation」と言う一つのリソースでその内部でこれらの処理を行うと言う、 いわゆるオブジェクト指向というか、クラス構成のようなAPIが望ましいという事。 この書籍では、関数名などが書かれていて、非常に難しく読みづらく書かれていました。

良いAPIのポイント

ユーザーが必要とする機能がある 当たり前ですが、APIへの問い合わせをしたいけどその機能がないなんてことになると、「使いずらいAPI」と思われます。 実行可能である 機能はある程度あるけど、実行できない(実行するのが複雑で困難)場合は、「実行できない」という事につながります。 表現力がある RESTfulAPIの場合に、実行する命令が英単語になっているケースが多いですが、これがわかりにくい、いわゆる表現力が無いと、とてもじゃ無いけど良いAPIとは言えません。 シンプルである APIに限りませんが、通常のプログラミングデザインパターンにおいても、複雑にすることのメリットは何一つありません。 予測可能であること 飛行機の予約をする場合に、飛行機の「フライト一覧の取得」や「空席確認」などの情報取得ができるということは、誰でも予測すると思いますが、こうした予測の通りの機能が備わっている事が重要です。

APIのデザインパターン

「車輪の再発明」をどの程度"良し"とするかが書かれています。
それぞれの場合に対して、カスタマイズする時の難易度などの表。
名前 通常のプログラミングのデザイン・パターンには、ストーリーがあって、それに対するシナリオがあります。 それぞれの命令に対するイベントなどの名前や、概要とする説明が明確にないといけません。 対象とする問題 ソリューションAPIの場合、問題(課題)があって、それを解決する手段としてAPIが使われます。 その課題となる対象の問題が明確に理解できないといけません。 概要 APiで使用する実際のデータベースや各種のパラメータの、いわゆる仕様という部分が明確になっていないといけません。 実装 エラー処理などを、メッセージも含めて忘れないようにしましょう。 トレードオフ APIを実装できない場合の事を考えておく必要もあります。

リソース識別子

リソースの命名は、以下のような重要ポイントがあります。 識別子としてのプレフィックスを含め、扱いやすさを追求するために、これらを認識しておきましょう。
- 使いやすいこと - 一意であること - 不変であること - 高速で簡単に生成できること - 予測不可能であること - 読みやすく、共有しやすく、検証可能であること - 情報密度が高いこと

標準メソッド

予測可能な一貫性のあるAPIを作るための標準メソッドの概要です。

ポリモーフィズム

オブジェクト指向プログラミングの用語です。 異なる方に対して、単一の共通インターフェイスを使用するという考え方。 いいプログラムの条件である、「再利用可能」という概念を考えると、当然のスタイルですね。

あとがき

この書籍、これまで読んだ技術書籍の中でも、(日本語で)読みづらさ"No.1"でした。 構成も、用語の説明かと思っていた章が、プログラムも提示されていない架空のサービスの内容の説明書きレベルだったり、 サンプルプログラムが、TypeScriptのみで書かれているんですが、記述ポイントなどが書かれておらず、一体どの部分に注目すれば良いのかが曖昧というのが500ページ以上もあるため、 苦行と言っても良いぐらいの読書でした。 読みたい人には何も言いませんが、このブログの要約で物足りる人も多いかと思います。

人気の投稿

このブログを検索

ごあいさつ

このWebサイトは、独自思考で我が道を行くユゲタの少し尖った思考のTechブログです。 毎日興味がどんどん切り替わるので、テーマはマルチになっています。 もしかしたらアイデアに困っている人の助けになるかもしれません。

ブログ アーカイブ