概要
この記事はMakuake Development Team Advent Calendar 2019の14日目の記事です。
趣味で駆け出し※URLルーティング自作マンをやっているので、URLルーティング自作界隈※に入門したい人に向けた記事となれば幸いです。
※駆け出しというキーワードが今年はWeb界隈で流行り？ましたね。私は去年末からURLルーティング自作を始めたので駆け出しだと思います。
※そんな界隈があるのかは知らないが、世界は広いのでたぶんある。
駆け出しURLルーティング自作マンの軌跡
見るに耐えないものではあるが、色々試行錯誤した過程を晒しておきます。
記事
スライド
試行錯誤してきた割にURLルーティングとしての機能を満たせない単純なミス※に最近気づいてしまったので、懺悔の気持ちを込めて今一度URLルーティングの自作について整理する目的も兼ねて記事を書きます。
※URLのパスパラーメータの扱いに関して残念なミスを発見してしまった。
モチベーション
URLルーティングを自作するモチベーションがどこにあるかという話しについて、思いついたことをリストアップしてみます。
- 自作の敷居が比較的低い
- URLルーティングはWeb系のエンジニアであれば馴染みがあるゆえ、仕様についての迷いが少なかったりするのでは？
- データ構造（木構造のアルゴリズム）の基本さえ理解できればベーシックなものは比較的自作しやすい（たぶん）。
- 多くの言語で参考実装となりうるライブラリが豊富にある。ヒントもアイデアもGithubに転がっている。
- 応用が効く
- 木構造のアルゴリズムを利用する仕組みのもの、例えばキーワードサジェストといった文字列を扱う機能の実装においては活かされる点が多いはず。
リストアップしたものの、ほとんど結果論で、楽しそうだからとりあえずやってみたというのが正直な感想だったりします。
URLルーティングとは何か
言葉通りに受け取ると、URlが名詞でルーティングが動詞なので"URLをルーティングする"モノが「URLルーティング」と呼ばれるわけですが、"URLをルーティングする"とはどういうことでしょうか。
この記事は入門を謳ってしまったので一つずつ言葉の解釈をしていくことにします。
URL
URLとは、ブラウザ上でよく見る"/"がいっぱいついてあるあの文字列のことです。ex. https://www.google.com/
インターネット上でのページのアドレス（住所）を表すもので、Uniform Resource Locatorの略です。
URLの文字列の形式は、以下のように定義されています。
<scheme>:<scheme-specific-part>
<scheme>の部分は、http・https・ftpといったプロトコル名がよく用いられますが、プロトコル名以外のスキーマ名も定義されています。 cf. Uniform Resource Identifier (URI) Schemes
<sceme-specific-part>の部分は、スキーマに基づく文字列が定義されます。例えば、httpやhttpsのスキームの場合は、ドメイン名とパス名（またはディレクトリ名）が定義されるルールになっています。
URLの詳しい仕様はRFC1738を参照してください。cf. rfc1738 - Uniform Resource Locators (URL)
RFC1738はインターネット標準（STD1）として位置づけられています。
ルーティング
ルーティング（Routing)とは、和訳すると経路制御という意味なります。
OSI参照モデルのネットワーク層の話しでいえば、ネットワーク間の通信を中継するルーターが"ルーティング"をの役目を担っています。このルーターは、ルーティングテーブルという経路表を持っていて、経路表に従ってパケットの受け渡しを仲介する、"ルーティング"を行っています。
URLルーティングの話しはネットワーク層の話しではないので、話しをアプリケーション層に戻します。
アプリケーション層での"ルーティング"※は、URLという情報をブラウザのリクエストから受け取り、受け取ったURLに基づいてデータを処理するために、URLと処理の仲介を行うことだと定義することができます。
※アプリケーション層の"ルーティング"という書き方は語弊があるかも。"URLルーティング"とは、に読み替えてもらうほうが無難。
ネットワーク層のルーターは経路表というデータ構造を持っていますが、アプリケーション層のルーター（URLルーター）も、URLに基づいて処理を振り分けられるようなデータ構造を持っています。どんなデータ構造かという話しは後述します。
URLルーティングを自作する
URLルーティングを自作する、というよりURLルーターを自作するというほうが言葉的に正しいような気がしますが、同義として扱うことにします。
Routerの位置づけはこんな感じです。
ここでルーターの要件についてざっくりと定義しておきます*。
- 静的なルーティングに対応すること
/foo/bar/というURLに対して、/foo/bar/という静的なルーティングの定義にマッチさせ、処理を返却することができること。
- 動的なルーティングに対応すること
/foo/bar/123というURLに対して、/foo/bar/:idといった動的なパスパラメータを持つルーティングの定義とマッチさせ、パスパラメータのデータを利用することができる形で処理を返却することができること。
最低限上記の要件を満たしていればルーターとしての基本的な機能を満たすことができるかと思います。
要件に元づいた仕様については実装次第で色々調整できるのでここでは明確に定義しておかないことにします。※
※GolangでのURLルーティングの実装について、Qiita - Go6 Advent Calendar 2019の20日目で書く予定です。
では、ルーターを自作するために、 ルーターがどんな処理を行っているか、データ構造の観点から考えてみます。
と、ここまで書いた時点で日を跨いでしまいそうなので、続きは明日の記事にします。
To Be Continued..
