5

基本的な REST API / フレームワークの設計に関して、URL ルーティング / マッピングについて何か大きなことが欠けているのではないかと心配しています。

URL をクラスに手動でマップする必要がある REST API フレームワークで通常見られるルーティング クラスなどの作成、およびクラス メソッド (アクション) の作成は、問題をカプセル化するのに失敗したように思えます。URLを動的に解析し、自動ルーターまたはフロントページコントローラーを使用することで、これをすべて決定できる場合。

GET https://api.example.com/companies/

すべての会社のリストを取得するコレクション リソース。

GET https://api.example.com/companies/1

ID で 1 つの会社を取得します。

すべてがテンプレートに従っているようです：https://api.example.com/<controller>/<parameter>/

利点 1: URL の分離と抽象化

典型的なルーティング クラスを持つ紙面上の利点の 1 つは、URL をリソース/物理クラスから分離または抽象化できることだと思います。そのため、必要に応じて、すべての企業を取得するGET https://api.example.com/poo/代わりに、任意の URL のようなものを使用できます。GET https://api.example.com/companies/

しかし、私が見たほとんどすべての例とユースケースで、目的のコントローラー、アクション、およびパラメーターに 1 : 1で一致する URL が必要です。

もう 1 つの考えられる利点は、リソース内のコレクション リソース、またはネストされたリソースが、URL マッピングと一般的なルーターを使用して実現しやすくなる可能性があることです。例えば：

GET https://api.example.com/companies/1/users/

また

GET https://api.example.com/companies/1/users/1/

これを動的に解析して、データを取得するために呼び出すコントローラー、使用するパラメーター、およびそれらをどこで使用するかを知ることができるパラダイムを考え出すのは非常に困難です。しかし、これを動的に機能させる標準的な方法を思いついたと思います。

これを手動でマッピングするのは簡単ですが。

GET https://api.example.com/companies/1/users/会社のコントローラーの代わりにユーザーのコントローラーに再ルーティングしてバイパスし、パラメーター「1」をWHERE句の会社IDに設定するだけです。

利点 1.1: 物理的な経路に縛られない

利点 1 の補足として、すべてが抽象的にマッピングされるため、開発者は API に影響を与えることなく URL スキームとフォルダー構造を完全に変更できるということです。ファイル、フォルダー、クラスを移動したり、名前を変更したりする場合は、マッピング/ルーティングを変更するだけで済みます。

しかし、API 全体を別の場所に移動しなければならなかったとしても、.htaccess の些細な変更ですぐに修正されるため、この利点も実際には得られません。

したがって、この：

GET https://api.example.com/companies/

に

GET https://api.example.com/v1/companies/

少しでもコードに影響を与えません。動的ルーターでも。

利点 2: 公開する機能を制御する

URL を解釈して解析するだけの動的ルーターよりも、一般的なルーター クラスが提供するもう 1 つの利点は、API コンシューマーに公開する機能を正確に制御できることです。すべてを動的に行うだけでは、ズボンを脱ぐようなものになり、消費者がシステム全体に自動的にアクセスできるようになります。

これは、すべてのルートを手動で定義してリソースにマップする必要がないため、動的ルーターの利点と考えられます。すべてが自動的にそこにあります。露出の問題を解決するために、API コンシューマーが使用することを許可してはならない機能のブラックリストを定義することで、おそらく反対のことを行うでしょう。ブラックリストを定義してから、使用可能なすべてのリソースをマッピングで定義すると、時間効率が向上する可能性があります。繰り返しますが、リスクも高いと思います。ホワイトリストを作成することもできます...これは典型的なルーターに似ていますが、拡張ロジックはまったく必要ありません. URL を動的ルーターに渡す前に、システムがチェックする URL のリストにすぎません。または、動的ルーター クラスのプライベート プロパティである可能性もあります。

利点 3: HTTP メソッドがうまく当てはまらない場合

典型的なルーターが輝くケースの 1 つは、既存のリソースと競合するアクションを実行する必要がある場合です。説明させてください。

ユーザークラス内で login 関数を実行して、ユーザーを認証したいとします。POST https://api.example.com/users/ただし、新しいユーザーを追加するために予約されているため、資格情報を使用して実行することはできません。代わりに、ユーザー クラスでログイン メソッドを何らかの方法で実行する必要があります。POST https://api.example.com/users/login/HTTP メソッド以外の動詞を使用しているため、どちらも使用したくありません。ただし、前に述べたように、典型的なルーターでは、これを直接マップすることができます。簡単。

url => "https://api.example.com/tenant/"
Controller => "users"
Action => "login"
Params => "api_key, api_secret"

しかし、もう一度、もっともらしい代替案を見つけました。ユーザーコントローラーをインスタンス化し、ログイン機能を実行する、ログインまたはテナントと呼ばれる別のコントローラーを作成することもできます。したがって、消費者はPOST https://api.example.com/tenant/、資格情報を使用して、非難することができます。認証。

ただし、この代替手段を機能させるには、別のコントローラーを物理的に作成する必要がありますが、URL マッパーを使用する場合は、その必要はありません。しかし、この懸念事項、機能、およびリソースの分離も非常に優れています。しかし、それが主なトレードオフかもしれません。単に URL ルートを定義するだけですか、それとも遭遇するニュアンスごとに新しいクラスを作成する必要があるのでしょうか?

私が見ていない、または理解していないものは何ですか? ここでコアコンセプトが欠けていて、単に無知ですか? 典型的な URL マッピングとルーティングのクラスと機能を持つことには、私が気付いていないだけのメリットがありますか、それともほとんどわかっているのでしょうか?

4

1 に答える 1

1

あなたが説明するルーティングの多くの利点は正しく、物理マッピングについてあなたが言っていることのいくつかも真実です。過去数年間のルーターに関する私の意見に影響を与えた経験/実用的な情報をいくつか紹介したいと思います.

  1. まず第一に、MVC 設計パターンに従ってアプリケーションを設計すると、URL の動的解析が (ほとんどの場合) うまく機能します。たとえば、階層型 MVC フレームワークである Kohana を使用して非常に大きなアプリケーションを作成したことがあります。これにより、ネストされた URL を作成するためにコントローラーとモデルを拡張できます。一般に、これは非常に理にかなっています。しかし、アプリケーションをより機能的にするために、1 回限りの URL の必要性を中心に、クラス全体とモデル システムを構築することにあまり意味がない場合が多くありました。しかし、MVC が使用している設計パターンではない場合もあり、そのため MVC は API の定義機能ではなく、このシナリオではルーティングが優れています。この問題は、構造的に自由度の高いフレームワークで遊んでみると簡単にわかります。

  2. 人々が考えているよりも多くの場合、完全に機能する API には、使用できる主に RESTful なエンドポイントに加えて、RPC の要素が含まれています。これらの追加機能は、既存のリソース メソッド マッピングを装飾するときに、消費者としてより意味があるだけではありません。これは、ほとんどのアプリケーションを構築し、ほとんどのベースをカバーした後に発生する傾向があり、そうでないリソースに関連して追加したい小さな機能がいくつかあることに気付きます。 CREATE / READ / UPDATE / DELETE カテゴリにきれいに収まります。見ればわかります。

  3. 控えめに言っても過言ではありません。コントローラーとモデルの実際の構造をハッキングしたり、本質的に同じルールに従っていないエンドポイントを追加することだけを目的として追加、削除、変更を行ったりしない方がはるかに安全です。他のコントローラー メソッド (API エンドポイント)。

  4. もう 1 つの非常に重要なことは、API エンドポイントは実際には、私たちが認識しているよりも男性的であるということです。つまり、月曜日にはエンドポイントの構造に問題がなく、金曜日には、これらの API 呼び出しをすべて別の構造に変更する必要があるという上からこのタスクが送信されます。大丈夫。しかし、大規模なアプリケーションの場合、非常に大量のファイルの名前変更、クラスの名前変更、リンケージ、およびあらゆる種類の非常に壊れやすいコードが必要になります。使用しているフレームワークに、クラスの命名、ファイルの命名、物理ファイル パス構造などに関する厳密な規則がある場合...想像してみてください。新しい構造で機能するようにクラス名を変更すると、次のようになります。古いクラスをインスタンス化したコードのすべての行を探し出し、それを変更します。さらに、そのシナリオでは、問題は、コードが API の URL 構造と密接に結合されていることであり、URL の変更が必要になった場合に保守が容易ではないことであると言えます。

いずれにせよ、特定のアプリケーションに最適なものを決定する必要があります。しかし、ルーターを使えば使うほど、ルーターがとても便利な理由がわかります。

于 2013-10-07T20:36:04.617 に答える