0

そこで、特定の情報専用の大きなファイル セットではなく、それぞれが汎用目的専用の小さなコンテンツ ファイル セットで構成される Web サイト アプリケーションを構築しています。つまり、/index.php、/aboutme.php、/contact.php などの代わりに、/index.php (基本的には HTML と を含むシェル) だけがあり、次に content.php、error.php があります。 、404.phpなど。

コンテンツを配信するために、「ディレクトリ構造」と関連するコンテンツをデータ テーブルに保存し、URI をキャプチャしてから、データ テーブルにクエリを実行して、保存されている「ディレクトリ構造」と URI が一致するかどうかを確認する予定です。一致した場合、関連するコンテンツがアプリケーションに返され、Pear の HTTP_Request2 を使用して content.php にリクエストが送信されます。次に、content.php は、データベースから返された適切なコンテンツを表示します。

編集1：例：

  • ユーザーがブラウザに www.somesite.com/contact/ と入力します
  • index.php の読み込み
  • index.php の HTML ヘッダーの上流にあるスクリプトは、次のことを行います。
    • mysql クエリを送信し、WHERE path = $_SERVER[REQUEST_URI]
    • 一致するものが見つかった場合は、表示のために /pages/content.php に設定$content = $dbResults->contentして POST します。$content/pages/content.php と /index.php が実際にコンテンツを配信していますが、元の URI は保持されます。
    • 一致するものが見つからない場合、/pages/404.php の内容がユーザーに返されます。ここでも、index.php と /pages/404.php が実際にコンテンツを配信しているにもかかわらず、元の URI が保持されます。

これは RESTful なアプローチですか? 一方では、URI は特定のリソース (データ テーブル内のタプル) にアクセスするために使用されていますが、他方では、私は常に「リソース」を実際のディレクトリ内の実際のファイルと考えていたと思います。

私は REST の純粋主義者になるつもりはありません。HTTP のより難解な側面と HTTP を操作するためのアプローチを深く掘り下げ、知識と理解を深めたいと考えています...

4

1 に答える 1

0

OK、私の結論は、私のアプローチには本質的に非 RESTful なものは何もないということですが、URI を使用してデータ テーブルにアクセスする方法は重要なようです。リソースのフル パスをデータ テーブルのそのリソースの行に格納することは、REST の精神ではないと思います。

代わりに、URI で参照される「ディレクトリ」ごとに一意のタプルを持つことが重要だと思います。私が今これをセットアップしている方法は、「コレクション」テーブルと「リソース」テーブルを作成することです。コレクションはリソースのグループであり、リソースは単一のエンティティ (コンテンツ ページ、画像など、またはネストと分類構造を可能にするコレクション) です。

したがって、たとえば、/portfolio は、/portfolio/spec-ads と同様に、コレクション テーブルとリソース テーブルのポートフォリオ エントリに対応します。ただし、/portfolio/spec-ads/hersheys-spec-ad は、リソース テーブルのエントリのみに対応します。そのエントリには、たとえば YouTube の Hershey's spec 広告の埋め込みコードが含まれます。

複数の「ディレクトリ」を使用して解析された URI からクエリを作成する効率的な方法をまだ考えていますが、そこにたどり着いています。次のステップは、別の方法で作業し、RESTful URI を使用してナビゲーション システムを構築するクエリを作成することです。繰り返しになりますが、URI、クエリ、およびデータ アーキテクチャを適切に関連付ける限り、元の質問で示したアプローチは RESTful であると思います。

この道は歩けば歩くほど好きになる…

于 2013-07-27T04:12:22.253 に答える