django rest framework #5

Posted at 2026-04-09

チュートリアル5と6のおおまかな振り返りと、チュートリアル全体を通して私が学んだこと、気づいたこと、感じたことなどを自分用にアウトプットしておきたいと思います。

チュートリアル5,6

チュートリアル5では、ハイパーリンクを実装した。これにより、APIに保存したデータ同士の繋がりを作って、相互にアクセスしやすくなった。

今までは、個々のデータを識別したり、紐づけたりするための項目はIDだった。個々のデータごとにユニークな番号をIDとして振ることで、どのユーザがどのデータを投稿したのかを分かるようにしたり、そのIDを辿って個々のデータの詳細ページにアクセスできるようにしていた。

それが、ハイパーリンクという技術を使うことで、このデータ同士の繋がりがさらに分かりやすく、扱いやすくなった。データ同士が、お互いのデータのURLを項目として保持することで、簡単にデータ間を渡り歩いて辿ることができるようになったのだ。

例えば、ユーザーの詳細ページを開くと、そのユーザが作成したデータの一覧が表示され、それは同時にURLになっており、クライアントはそれをクリックすれば、そのデータの詳細ページに遷移する事ができるようになる。

これによって、クライアントがAPIの使い方を理解していなかったとしても、ハイパーリンクをポチポチ押しているだけで、直感的にAPIの全ての機能にアクセスする事ができるようになる。

最後に、チュートリアル6でビューセットやルーターという機能を使い、コードのリファクタリングを行った。

リファクタリングとは、ソフトウェア開発において、外部から見たシステムの挙動を変えずに、内部の構成を改善するという意味である。これによって、API実装のためのコードがさらに軽量で、簡潔、明快なものとなった。

今まで、一つのモデルに対して、実装したい操作の内容ごとにクラスベースのビューを複数実装していた。それが、ビューセットを使用することで、一つのモデルに対して一つのビューセットの実装で済んでしまうのだ。

さらに言えば、urls.pyで定義していたURLパターンに関しても、ルーターという機能を使う事によって、今までと同じ挙動が、たったの一行で実装することが可能になった。

ただ、チュートリアルによると、どうやら必ずしもビューセットの使用が、常に最善の選択であるとは限らないそうだ。

ビューセットによる実装はとにかくコード量が短く、実装しやすいところにある。しかし裏を返せば、あまりにも抽象的で暗示的なコードの実装が、開発者の予期せぬ挙動を引き起こす場合もあるのかもしれない。

一方、ビューを一つ一つ丁寧に実装していくのは、手間がかかるが一方で、自分が欲しいと思う機能を柔軟に実装することを実現する。この「手間」と「カスタム性」がトレードオフであるという意味なのだと思う。

今週はDRFのチュートリアルに取り組んでいた。その経験を通して、私が学んだことや、感じたこと、考えたことなどをまとめていきたい。

フレームワークというのは、欲しい機能の実装を助けてくれる便利な型といったところだと思う。

システムを形にするだけでも、何もない所で1から作ろうとするのは大変だ。途方もない時間と苦労を必要とするだろう。しかし、「だいたいこういった機能を作成することがあらかじめ分かっていて、型にあてはめるだけでそれが簡単に実現する」これがフレームワークである。

機能を実装するために、必要な道具が既に一式揃っているから、開発者はインフラの整備に時間と手間を取られることなく、個々の事情に合ったAPIの開発に専念することができるようになる。

これがフレームワークの強みであり、言うなれば、受け継がれてきた先人の知恵であると言えるだろう。

フレームワークを使いこなすためには、経験の他に、以下のようなことがコツとしてあるだろう。

フレームワークに関わらず、世の中に存在するツールというのは便利だが、その柔軟性と対応力ゆえに、そのツールが備えている機能は非常に多岐にわたっており、最初からそれら全てを理解しようとするのは不可能であるか、もしくは時間を無為に浪費する事になる。

なので実際の所は、まず自分が何をしたいのかを明確にしておいて、そのためにどんな道具が用意されているのかを調べて、それを使っていくという向き合い方が現実的だろう。

フレームワークはその便利さゆえに、コードの中身がブラックボックス化してしまう傾向にある。これはある程度仕方のないことかもしれないが、一方で、自分が作り上げたシステムが予期せぬ挙動を起こしてしまうリスクも考えられる。

したがって、自分が書いたコードが何のためのもので、何をしているのかを少しでも理解しておくことが大切だと思われる。