質問

多くのフレームワークは / controller / action / {id} などのURL規則を使用しますが、それ以上の設定が必要な場合は、独自のルートを作成する必要があります。

バックエンドで / users / {id} / friends などのURLをどのように処理しますか? (ユーザーのすべての友人をリストするため)

コントローラーでは、次のようなものが適切だと考えています:

class User {
    function index() {
        echo 'user index';
    }
}

class Friend extends User {
    function index($user_id) {
        echo 'friend index';
    }    
}

その後、次のマップが作成されます。

/users              -> User::index()
/users/{id}         -> User::view($id)
/users/{id}/friends -> Friend::index($user_id)

FriendクラスをUserクラスの中に入れたかったのですが、どうやらPHPでそれができないので、これが思いついた最高の方法です。思考?

友達リストの編集に使用するURLは何ですか? / users / {id} / friends / edit は機能しますが、他の人の友達リストを編集してはならないため、適切ではないようです。 / account / friends / edit がより良い選択でしょうか?対応するコードをどこに配置しますか?フレンドコントローラー、ユーザーコントローラー、または特殊なアカウントコントローラーのいずれか

ボーナス質問:どちらが好きですか? / photos / delete / {id} または / photos / {id} / delete


答え:

だから、私が答えから集めたのは、「もの」が(「友人」のように)複雑ですが、独自のコントローラーはありません。モデルなしでコントローラーを提供できます。そうでない場合は、最も密接に関連するものを詰め込む必要があります。 URLは、コードを配置する場所に影響を与えません。ほとんどの人は、可能な限り / controller / action / {id} に固執すべきだと考えているようです。

拡張クラスについて、「厄介な」と言う以外に、実際にコメントした人はいませんでした。もし私が本当にそれを分離したいなら、おそらくFriendListはその場合により適切なクラスだっただろう。

すべての回答に感謝します:)

役に立ちましたか?

解決

あなたが話しているルートと、この構造を実現するためにサブクラスを使用する方法は、私には少し厄介なようです。 / controller / action / {id} の標準的な規則は単純なアクションには最適ですが、複雑なアプリケーションを作成する場合は常にカスタムルートを作成する必要があります。これらのルートを作成する際に使用する良いガイドラインはおそらくありますが、実際にはアプリケーション全体で一貫性を保ち、できるだけシンプルに保つことになります。

/ user / {id} / friends を" Friend "にマッピングする正当な理由がわかりません。コントローラ。 " friends "だけでなく、 User コントローラーのアクションですか?実際に特定の友人のページを表示するためにドリルダウンしたら、 Friend コントローラ( / friends / view / 123 )を使用するか、 User コントローラーを使用して、友人または現在ログインしているユーザー( / user / view / 123 )で機能するようにします。

Re:おまけの質問です。 / photos / delete / {id} / controller / action / {id} )が一番だからです。広く受け入れられているメカニズム。

他のヒント

/ photos / {id} / delete をお勧めします。私の推論では、URLの末尾から1つのコンポーネントを取り出しても、それは意味をなすはずです。

/ photos / {id} の動作を想定するのは非常に簡単です。その {id} の写真セットを表示します。

しかし、 / photos / delete はどうすればよいですか?それは本当に不明瞭です。

/ controller / action / id にはデフォルトの規則があることは知っていますが、その構成はコントローラのクラス/メソッドアーキテクチャへのマッピングのためです。コードを収容するためにUIを整理することは良い考えではないと思います(URLはある意味UIの一部です)。


再コメント:はい、 / photos / {id} は、特定の写真をそのIDで表示する方が意味があります。 / users / {id} / photos を使用して、おそらくコレクションを表示します。それはあなた次第です。

ポイントは、UIをコード編成ではなくユーザーの観点から考える必要があるということです。

どちらかを行うことができます。問題は、2つを混在させる場合です。 / users / {id} / friendsおよび/ users / friends / {id}" friends"のIDを持っている場合これは失敗します。これは些細なケースのように思えるかもしれませんが、IDにユーザー名を使用することは非常に一般的です。すべてのアクションに対してユーザー名を制限する必要があります。


/ {controller} / {action} / {id}

ができない場合があります

しばらく前にインディーズの音楽サイトを作りましたが、

/artist/{username}
/artist/{username}/albums
/artist/{username}/albums/{album}

条件をテストしたくないので、実行しませんでした

/artist/{username}/{album}

" albums"という名前のアルバムを持つ人をチェックしたくないので

できたかもしれません

/artist/{username}
/artist/{username}/albums
/albums/{album}

しかし、その場合、アーティスト名とアルバム名の両方をURLに含めるというSEOの利点が失われます。また、この場合、アーティストが他のアーティストと同じアルバム名を持っているのが一般的であるため、アルバム名が一意になるように強制しますが、これは悪いことです。

純粋な / {controller} / {action} / {id} を実行できますが、SEOが一部失われ、URL短縮ができなくなります。

/artist/view/{username}
/artist/albums/{username}
/album/view/{album}

例に戻ります。

  

/ users / {id} / friends / editは機能しますが、   しかし、それは適切ではないようです。   誰かを編集してはいけません   他の友だちリスト。

この場合、ユーザーIDは、何らかの方法でセッション中を想定している重複情報であるため、 / friends / edit である必要があります。一般に、URL展開ではなくURL短縮をサポートする必要があります。

(ボーナス質問) どちらも、 REST を使用しません。 DELETE / photo?id = {id}

データの保存方法にも依存します。場合によっては、モデルのエンティティになるために「フレンドリスト」が必要になると想像できます。論理的なアプローチは、各フレンドリストに一意の識別子を指定することです。これは主キーです。

友人リストの主キーのみを編集または削除する必要があるため、論理的には次のルートになります...

/ friends / edit / {friendListId}

決定するのはあなた次第です。 pix0rが述べたように、小さなアプリケーションの規約は / {controller} / {action} / {id} です。{id}は、ほとんどのWebサイトのアクションと一致するようにオプションである必要があります。場合によっては、アプリケーションが大きくなり、3つ以上の要素を持つ特定のルートを定義する必要があります。場合によっては、特定のエンティティの意味が大きくなり(上記の例)、カスタムコントローラーを定義することもできます(これにより、デフォルトルートが再び完全になります...)。

デフォルトのルート / controller / action / id に固執しますが、最初はすべて(友達など)のコントローラーの作成を開始しません。 Model-View-Controllerパターンを使用すると、すべてのルートリンクとアクション(フォームなど)がルートとアクションに基づいて生成される限り、後でルートを変更することが非常に簡単になります。そんなに気にする必要はありません:)

URL自体はあまり重要ではありません。さらに重要なことは、各コントローラーに何が入るかです。この例では、友人リストに User クラスを拡張しました。友だちのリストが本当にユーザーのリストにすぎない場合は、 Users コントローラーを拡張して、ユーザーのリストを1か所で処理できるようにする必要があります。

class Users {

    public function index() {
        $users = $this->findUsers();
    }

    protected function findUsers($userId=null) { ... }
}

class Friends extends Users {

    public function index($userId) {
        $users = $this->findUsers($userId);
    }
}

どのクラスを拡張するかわからない場合は、各クラスから必要なものを書き出し、最も長いリストを持つものを選択してください。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top