REST API開発に特化したWebフレームワークがもたらす生産性の向上

皆さんはREST APIの開発にどのようなフレームワークをお使いでしょうか？ これまで、個人的には Flask 等の軽量なWebフレームワークを使って開発することが多く、REST API開発に特化したWebフレームワーク（以下、APIフレームワークと呼ぶ）を使った経験はありませんでした。 しかし先日、業務で Django REST Framework に触れる機会があり、REST APIの実装に必要な機能の多くが提供されていて、圧倒的に少ないコーディング量で開発が完了することを実感できました。例えば、フィルタリング（URLクエリストリングで検索条件等を指定し、取得する値を絞り込む）機能は、一から実装するとなると文字列をパースして、バリデーションして、クエリに渡して……、と結構面倒ですが、Django REST Frameworkではビルトイン機能として提供されているので、最小限のコードで実現できました。そこで俄然、APIフレームワーク全般について興味が湧きましたので、色々調べてみました。

代表的なAPIフレームワーク

REST API開発への特化を名乗るフレームワークは数多く存在しますが、Web上の評判などを調べた限り、以下のフレームワークが現在よく使われているようです。

• Django REST Framework（Python）
• Eve（Python）
• Sails（Node）
• LoopBack（Node）
• Feathers（Node）
• Restify（Node）
• Dropwizard（Java）
• Ruby Grape（Ruby）

また、以下のフレームワークは、誕生して日が浅いために現時点では上記のフレームワークほどポピュラーではないものの、後発のメリットを活かした先進的な設計・機能で、注目に値するようです。

• FastAPI（Python）
• hug（Python）
• Micronaut（Java)
• Light（Java）
• API Platform（PHP）

フレームワーク以外の選択肢

フレームワークという範疇からは外れますが、既存のDBに対するCRUD操作用REST APIを簡単に構築できる以下のようなソフトウェアもあります。開発時に使うモックサーバ用途等、とにかくお手軽に済ませたい場合はうってつけかもしれません。

• PostgREST
• Strapi
• KeystoneJS

APIフレームワークの機能

次に、一般的なWebフレームワークではあまり実装されていない、APIフレームワークが差別化を図っているポイントとなる機能を見てみます。 ここで紹介する機能は、前述のフレームワークの多くで提供されています。

CRUDエンドポイント実装支援

REST APIの場合、エンドポイントに対する要求仕様は概ね似通ってきます。これら頻出の機能のデフォルト実装を提供することがAPIフレームワークの最大の目的と言えるでしょう。 例えば、以下のようなREST API実装ではおなじみの処理が、多くのAPIフレームワークで組み込まれています。

• フィルタリング
• ページネーション
• APIバージョンごとのハンドラ切り替え
• 単位時間当たりのリクエスト数制限
• エンドポイントごとのアクセス権限設定
• JWT形式のアクセストークンのサポート

また、RESTに加え、GraphQLのインタフェースも選択できるフレームワークもあります。

データ処理に関する支援

一般的なWebフレームワークの多くではO/Rマッパーを用い、DB上のレコードとプログラムが扱うデータオブジェクトとの間の変換を自動化しています。 また、両者のスキーマ定義は1ヶ所に集約され、仕様変更時の複数箇所の修正や定義の乖離等が起きないようになっています。

APIフレームワークの多くではこれに加え、データオブジェクトとAPIリクエスト・レスポンスのボディ部分とのマッピングも行います。 結果、DB上のデータとリクエスト・レスポンスのボディのスキーマが同じであれば、シリアライズ・デシリアライズが自動で行われ、CRUD操作用のREST API開発が最小限のコードで完結します。 もちろん、そのような単純な仕様のAPIはレアケースであり、多くは個々のAPIごとにカスタマイズが必要となります。 ただ、メインのデータの流れをフレームワーク側で実装済みなので、API開発者はバリデーションやセンシティブなデータの除去等、各API固有の詳細のみを実装すればよく、コーディング量は大幅に削減できます。 データスキーマの定義が集約されていることで、仕様変更等にも強くなることが期待できます。

ドキュメンテーション等、開発フローの支援

REST API開発に欠かせない作業として、リファレンスマニュアルの作成があります。 最近では、APIドキュメントはOpenAPI形式で生成し、Swagger UIのようなツールを使ってリファレンスとして参照することが多くなってきました。

APIフレームワークの多くは、OpenAPIドキュメントを自動生成する機能を持ち、文書作成の手間を減らしつつ、実装とドキュメントの乖離を防げるようになっています。 また、Swagger UIが同梱され、APIの簡易動作確認などに使えるようにしているフレームワークもあります。

APIフレームワークのメリット・デメリット

APIフレームワーク採用のメリット・デメリットを考察してみます。

メリット

1. 開発生産性の向上

前述のようなREST API実装向け機能の提供により、開発工数の大幅な削減を期待できます。 フレームワークによっては、ほとんどコーディングすることなくREST APIを構築できるものもあります。

2. API仕様検討の省力化

REST APIの仕様決定にあたっては、URL・クエリパラメータの仕様や各種規格への準拠等、考慮すべき点が多く、使いやすいAPIを設計するにはセンスや経験が必要となります。 しかし、APIフレームワークを採用すれば、フレームワークがもたらす制約と引き換えに、（そのフレームワークが提案する）ベストな仕様のREST APIが自然と手に入ります。 結果、REST API開発者は本来の関心事であるドメイン固有のロジックの実装に集中することができます。

3. API実装のベストプラクティスの踏襲

良質なAPIフレームワークでは、フレームワークに沿って実装するだけで、テストや保守のしやすさまで考慮されたコードとなるように設計されています。

デメリット

1. フレームワークがもたらす制約

APIフレームワークを採用した場合、そのレールから外れたコードの実装は難しくなる場合があります。 例えば、URLの仕様等、自由に変更できないフレームワークも存在します。 あらかじめ、開発するREST APIの要求仕様とAPIフレームワークのもたらす制約とを事前に検討しておく必要があります。

2. 依存ライブラリの増加

ほとんどのAPIフレームワークが、汎用的なWebフレームワークを基盤として実装されています。 したがって、APIフレームワークの使用にあたっては、基盤となっているフレームワークに関する知識も要求されることがあり、導入に当たっての学習コストには注意が必要です。 もちろん、依存ライブラリの増加によって、それぞれの更新等に伴う保守コストが増えることも、長期運用予定のサービス開発の場合は留意する必要があるでしょう。

まとめ

以上、APIフレームワーク全般について簡単にまとめてみました。 もちろん、本格的なサービス開発への採用に当たっては、上では触れていないセキュリティやパフォーマンス等についてもじっくり検証してからになりますが、社内のちょっとしたシステムの開発時等には今後、積極的に使っていこうと考えています。