2

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

/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 がより適切なクラスだったでしょう。

すべての答えをありがとう:)

4

5 に答える 5

2

またはのいずれかを行うことができます。問題は、2つを混ぜたときです。/users/{id}/friends および /users/friends/{id} 誰かが「友達」の 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 は機能しますが、他の人の友達リストを編集するべきではないため、適切ではないようです。

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

(おまけの質問) どちらも、私はRESTを使用します。DELETE /photo?id={id}

于 2009-06-22T22:53:58.307 に答える
2

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

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

/photos/delete/{id}Re: おまけの質問ですが、 ( ) に固執し/controller/action/{id}ます。これが最も広く受け入れられているメカニズムだからです。

于 2009-06-22T22:00:03.093 に答える
2

私は好むだろう/photos/{id}/delete。私の推論は、URL の末尾から 1 つのコンポーネントを削除しても、意味があるはずだということです。

何をすべきかを推測するのはとても簡単/photos/{id}です: そのための写真のセットを表示し{id}ます。

しかし、何をすべき/photos/deleteでしょうか？それは本当に不明です。

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

再コメント: はい、/photos/{id}特定の写真を ID で表示する方が理にかなっているかもしれません。 /users/{id}/photosおそらくコレクションを表示します。それはあなた次第です。

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

于 2009-06-22T22:01:21.393 に答える
1

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);
    }
}

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

于 2009-06-22T23:28:46.893 に答える
1

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

編集または削除するにはフレンドリストの主キーのみが必要なため、これは論理的に次のルートになります...

/friends/edit/{friendListId}

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

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

于 2009-06-22T22:19:18.407 に答える