概要

  • この文書内での「オブジェクト」は「Web上に存在しブラウザで閲覧・操作できるとユーザーが思っているもの」
  • それがURLで一意に示されるものだと、GUIでの操作の必要なく共有・伝達可能になり、人も機械も読みやすいのでそうあるべき。
  • 実際にどのようにデータが保持されているかは関係無いが、乖離すると実装が難しくなる。

ページからデータへ、簡単な歴史のおさらい

WWW(World Wid Web)はハイパーテキストという、文書同士がハイパーリンクでつながったテキストとして誕生した。 他の文書へリンクする・されるためにURLが必要で、それをブラウザで表示すると文書のページとして表示された。 この時点ではサーバーに上げられたファイルとURLがほぼ一対一になっており、当然ファイルとオブジェクトはほぼユーザーの中で一致していた。

その後CGIが出てくる。 Perlなどのプログラムによって、データベースに格納されたデータやそれらを組み合わせたものを一つのページとして生成することが可能になった。 これは、URLとファイルの1対1の関係性を崩した。
また、フォームによってデータをブラウザから入力できるようになった。 初期のBBS、掲示板などは、オブジェクトを作れる場所となり、UGC(User Generated Content)やCGM(Consumer Generated Media)を生むことになる。
結果としてオブジェクトはデータベース内のデータに紐付けられることになる。1

更にWeb2.0によって、ページを遷移しない柔軟なデータのやり取りが可能となり、より操作性の高いWebアプリケーションが出てくる。 これによってブラウザで表示されるページの内容が動的に変化することになった。

例えば、GoogleMapはブラウザ上の地図でドラッグ＆ドロップすると、バックグラウンドでサーバーとアクセスを行う。 しかし、ある地点を示すURLが存在し、それ入力すれば常にその地点をブラウザに表示できる。 よって、そのURLを友人にLINEなどで渡すことで、同じ地点の地図情報を共有できる。 この「情報を一文で共有できること」が、当初から続くWebの利点であり、ファイルの送付やスクリーンショットをしてまで共有する必要が無い。2

このブラウザ上でのJavaScriptの動作により、よりデスクトップ・ネイティブアプリケーションと呼ばれるものに近い動作ができるSPA(single-page application)が作れるようになった。 SPAの問題点があるとすれば、あるページを開いた後、特定の操作をしないと表示されないデータがある、ということだろう。 これは作りの悪いCGIでも起こる現象だが、ユーザーの操作によって画面上に表示されているオブジェクトが変わってもURLのパスが変化しない場合、劣化デスクトップアプリケーションになりやすい。 もちろん適切なルーティングをすればそういった問題は起こらないが、ここで完全にオブジェクトとデータがAPIを通すことになり、更に乖離することは強調しておきたい。

データと乖離したオブジェクト、それらをつなぐルーティングとORMの関係

こうして、オブジェクトとしてのファイルとURLが一致した状態から、APIを通してアクセスしたデータベースからデータを取得してURLに紐付けるSPAまで、Webは変化してきた。3

WebのフレームワークであるRailsでは、推奨される実装方法としてルーティングで階層的なパスとデータを紐付けている。 ある記事のURLなら https://example.com/articles/1 のようにだ。 更にそこにコメントが付き、単一のオブジェクトとしてアクセスできるようにするのであれば、https://example.com/articles/1/comments/1 のように作る。
また、Next.jsのルーティングでは、pages配下のディレクトリの配置とURLのパスを紐付けている。 これらの例から言えることは、Linuxのディレクトリ構造に似た階層は、人間にとって情報管理としてやりやすいからであろうと予想される。4

Webアプリケーションにおいて、オブジェクトとURLにわかりやすい対応関係があることは、ユーザーにとっても開発者にとっても理解しやすいのだろう。 さらに、画面を操作すること無くデータにアクセスできることは、クローラーなどの機械にとっても使いやすい。

主にRDBで保持されているデータを一つのオブジェクトとして取得する場合は、ORM(Object-relational mapping)が必要になる。5 これを究極に推し進めたのがActiveRecordであり、Railsというフレームワークなんだろう。
URL（のパス） → ORM → RDB内のレコード を一貫して紐付け、データの閲覧と操作をシンプルに表現している。6

オブジェクトを生み出すフォーム

誰かがどこかでデータを作らないとオブジェクトは発生しない。 それはフォームによって実装され、どこかのデータベースやストレージで保持され、様々な方法で呼び出されて閲覧される。 Web2.0以降、複雑なGUIを持つブラウザが出てきて、テキストデータだけではなく、画像処理もブラウザ上でできるようになってきた。

ブラウザがただのViewerではなく、Editorとしても使われることで、ユーザーはWeb上に自身が生成したオブジェクトを持つことになった。 当然、ユーザーは作ったオブジェクトは特定のURLでまた閲覧できるものと認識するし、必要があるなら更新できるとも思っている。7

結論

ユーザーはブラウザでWebにアクセスし、画面上に表示されているデータをオブジェクトとして認識する。 ただ、特定のデータにアクセスするために、画面上での操作が必要である場合（CGI、SPAなどの実装で発生しうる）、他者への共有や機械可読性に問題が出る。
URLで一意にユーザーが認識しているオブジェクトを指し示すことで、共有や再利用がより簡単になる。 また、開発者から見れば、そのような実装になるようなフレームワークを選択・実装してくことが、今後もベターだと考えられる。

  1. 更に、ユーザーを識別できるようになったことで、同じURLでも違う内容が出ることがある。しかし、これは「そのユーザーが閲覧できるもの」という意味では同じものを示している。 ↩

  2. もちろん、権限を限定されている場合は別。そういう場合は他の手段であっても共有するべきではないが。 ↩

  3. 当然、今でもファイルにアクセスするタイプのWebページはあるし、SSGなどの新しい方式によって作られてもいる。 ↩

  4. そもそもURLのパスの出自はそこからのはず。とはいえ、一定量以上の情報量になってくると、階層的な管理には限界がある。多数の人間が生み出す情報は、それ自体が一種の自然物であり、木構造での分類に耐えられなくなるからだ。 ↩

  5. ここでは意図的にプログラミング上のObjectとユーザーの頭の中にあるであろうオブジェクトを混同させている。 ↩

  6. 極端なことを行ってしまいえば、mysqladminなどでデータベースそのものを操作させてしまえば良いのだが、そこまでのリテラシーをユーザーに求めるわけにもいかないだろう。 ↩

  7. 更にWebアプリケーションはデータを集約し、集計することで新しいオブジェクトを生む。統計データやレコメンドシステムはデータを集約することで実現できた。 ↩