2

RESTful URL と、URL をネストしないことの背後にあるすべての理論については十分に理解していますが、Amazon、StackOverflow、Google などのエンタープライズ アプリケーションでこれがどのように見えるかはまだよくわかりません。

Google には次のような URL があります。

アマゾンはこのように：

そして、次のような StackOverflow:

私の質問は、このようなシステムの URL を作成する上でのベスト プラクティスは何ですか? いつURLにパラメータを保存し始めますか? これらの大企業は、Ruby コミュニティで熱く議論されているルール (たとえば、URL をネストすることはほとんどありません) に従っていないようです。 URL を入れ子にしないという考えは、ブログよりも大きなものではうまくいかないようです。

任意のヒント？

4

2 に答える 2

6

Ruby コミュニティの「ルール」にとらわれすぎないようにしてください。URL を入れ子にするときにやり過ぎてはいけませんが、適切な場合は、理由により Rails フレームワークに組み込まれているため、それを使用してください。

リソースが常に別のリソース内にある場合は、入れ子にします。それは何も悪いことではありません。ルートパスが非常に長くなり、少し混乱する可能性があるため、1 つよりも深くなると、少し面倒になることがあります。

また、ネスティングと名前空間を混同しないでください。example.com/admin/products/1234/edit が表示されたからといって、ネストが発生しているとは限りません。ルーティングは、実際にはコード レベルではない場合でも、ネストされているように見せることができます。

私は個人的にネスティングの大ファンであり、アプリケーションで頻繁に (1 レベルのみ、場合によっては 2 レベル) 使用します。また、ID だけでなく単語を使用するパーマリンク スタイルの URL を追加すると、より視覚的に魅力的になり、ネストされているかどうかに関係なく、SEO に役立ちます。

于 2009-11-20T22:44:23.253 に答える
1

REST および/またはルートのネストに対する賛否両論は、API を公開する方法に大きく関係していると思います。アプリの API を公に公開することを気にしない場合、特に REST の背後にある理由に同意しない場合は、RESTful 設計に厳密に従うことは時間の無駄であるという議論があります。あなたの選択。

クライアント (ブラウザー以外) がアプリからの情報にアクセスする方法を考えると、設計プロセスに役立つことがわかりました。API の観点からアプリの設計を考える最大の利点の 1 つは、不要な複雑さを排除できることです。これが、Rails コミュニティでネストされたルートに関して耳にする警告の根源です。これは、状況が少し複雑になってきていることを示しており、一歩下がってアプローチを再考する時期かもしれません。「ブログよりも大きな」システムは、本質的に複雑である必要はありません。ある部分もあるかもしれませんが、別の視点からデザインにアプローチすると驚くかもしれません。

要するに、コミュニティの特定の部分から耳にする可能性のあるドグマのいくつかを、あなたのデザインについてより深く考えるためのガイドやシグナルとして考えてみてください。厳密な REST は、アプリケーションをどのように構築するかを考える別の方法にすぎません。

于 2009-11-21T03:16:11.973 に答える