WebエンジニアにとってAPIって切っても切り離せない、腐れ縁カップルなんですよ。
RestfulAPIから、簡易なバッチシステムまで、世の中にはいろいろなAPIがあり、星の数ほどのフレームワークが存在します。(オレオレFW含む)
そして、プログラミングのデザインパターンを理解した直後ということもあり、APIのデザイン・パターンもついでに学習してしまおうと、
今更ながら書籍を手に取ってみました。
digital-text
(2026-03-07 時点)
レビュー
★★☆☆☆正直言って、あまり学習にはならなかったな〜という読後感です。 それ以外に、この書籍は、Kindleで購入したんですが、scanしただけの書籍なので、kindleでの紙スキャンだけ書籍は基本的にどんなにいい内容であったとしても、星が下がってしまいます。 売り手の安直感が拭えません・・・ さらに、誤字脱字が、この書籍は頻繁にあるため、読んでいてそういう箇所が気になって仕方がなかったんですよね。 なので、内容があまり入ってこないというのも星の低さの原因でした。 もっと突っ込んで言うとすると、翻訳も古い翻訳システムでも使ったのかと言うぐらい、日本語でワザとわかりにくく書いているのか?と疑いたくなるぐらいの読みづらさ・・・ コンテンツクリエイティビリティの低さがどうしても気になってしまったんですね。 肝心のAPIデザインパターンはというと、もちろん学びになる点はありはしましたが、かなり局所的な事が長々と指摘されていたため、個人的には肌感が合わないという感覚が終始抜けませんでした。
この書籍で学べるポイント
リソース思考API
コンピュータに対して、サブルーチンやメソッドを呼び出すスタイルを、RPC(リモートプロシージャコール)と呼びます。 ライブラリ関数である、プロシージャをコール(呼び出し)する、この処理は、全てのAPIには向かないそうです。 飛行機チケット処理のAPIを例にとると、・フライトの情報表示 ・フライト予約 ・予約のキャンセル ・予約の変更 ・オプションの追加これらを、それぞれのAPIの関数でアクセスさせるよりも、 「FlightReservation」と言う一つのリソースでその内部でこれらの処理を行うと言う、 いわゆるオブジェクト指向というか、クラス構成のようなAPIが望ましいという事。 この書籍では、関数名などが書かれていて、非常に難しく読みづらく書かれていました。
良いAPIのポイント
ユーザーが必要とする機能がある 当たり前ですが、APIへの問い合わせをしたいけどその機能がないなんてことになると、「使いずらいAPI」と思われます。 実行可能である 機能はある程度あるけど、実行できない(実行するのが複雑で困難)場合は、「実行できない」という事につながります。 表現力がある RESTfulAPIの場合に、実行する命令が英単語になっているケースが多いですが、これがわかりにくい、いわゆる表現力が無いと、とてもじゃ無いけど良いAPIとは言えません。 シンプルである APIに限りませんが、通常のプログラミングデザインパターンにおいても、複雑にすることのメリットは何一つありません。 予測可能であること 飛行機の予約をする場合に、飛行機の「フライト一覧の取得」や「空席確認」などの情報取得ができるということは、誰でも予測すると思いますが、こうした予測の通りの機能が備わっている事が重要です。APIのデザインパターン
「車輪の再発明」をどの程度"良し"とするかが書かれています。 それぞれの場合に対して、カスタマイズする時の難易度などの表。 名前 通常のプログラミングのデザイン・パターンには、ストーリーがあって、それに対するシナリオがあります。 それぞれの命令に対するイベントなどの名前や、概要とする説明が明確にないといけません。 対象とする問題 ソリューションAPIの場合、問題(課題)があって、それを解決する手段としてAPIが使われます。 その課題となる対象の問題が明確に理解できないといけません。 概要 APiで使用する実際のデータベースや各種のパラメータの、いわゆる仕様という部分が明確になっていないといけません。 実装 エラー処理などを、メッセージも含めて忘れないようにしましょう。 トレードオフ APIを実装できない場合の事を考えておく必要もあります。リソース識別子
リソースの命名は、以下のような重要ポイントがあります。 識別子としてのプレフィックスを含め、扱いやすさを追求するために、これらを認識しておきましょう。- 使いやすいこと - 一意であること - 不変であること - 高速で簡単に生成できること - 予測不可能であること - 読みやすく、共有しやすく、検証可能であること - 情報密度が高いこと




0 件のコメント:
コメントを投稿