1

ASP.NET MVC (および一般的な MVC) の標準テンプレートは{controller}/{action}/{id}のようですが、現在取り組んでいるプロジェクトでは、それが適切かどうかわかりません構造。たとえば、車を制御するアプリケーションがある場合、以下の構造を持つ方が理にかなっています。

  {car-rego}/{controller}/{action}/{data etc}

車 (ナンバー プレートで識別) は操作を実行するリソースであり、機能の論理的な分離はコントローラーとアクションに分かれているため、これは私には理にかなっています。これにより、次のような URL が生成されます。

/ESX-121/Power/On
/ESX-121/Speed/Set/100
/ESX-121/Speed/Current -- get the current speed (could be /ESX-121/Speed also)
/ESX-121/Turn/Left
/ESX-121/Speed/Set/90
/ESX-121/Power/Off

これがデフォルトのパターンに従った場合、次のようになります。

/Power/On/ESX-121
/Speed/Set/ESX-121/100
/Speed/Current/ESX-121 -- get the current speed (could be /Speed/ESX-121 also)
/Turn/Left/ESX-121
/Speed/Set/ESX-121/90
/Power/Off/ESX-121

私にとって、最初のオプションは、読み取り可能な URL があり、リソース識別子が一定の論理的な場所にある限り、はるかに理にかなっています。たとえば、/Speed/Set/ESX-121/100は、ESX-121 の識別子を持つスピード タイプのリソースがあることを示唆していますが、実際にはそうではありません。操作は車上にあります。

このような場合、URL と関連するコントローラーとアクションをどのように構造化しますか? これは受け入れられる解決策だと思いますか、それともこれを構造化するためのより良い方法はありますか?

4

4 に答える 4

5

「哲学的」な観点から、大きな問題があります。

速度の設定など、ほとんどすべてにGETリクエストを使用しているようです。REST の背後にある考え方は、ESX-121 リソースにアクセスすると、現在の状態 (この場合は速度、方向、オンの場合など) を表すことができるというものです。

車の表現を URL に POST すると、現在の状態が事実上変更されます。(たとえば、表現に XML を使用している場合は、投稿できます。

<car><id>ESX-121</id><speed>100</speed><car>

その速度を変更します。ASP.net MVC では、そのためのフォームを POST します。

あなたがやろうとしているのは、SOAP サービスのモデリング方法 (操作または動詞を対象とする) を REST サービスに適用することですが、これは実際には考えられません。

REST のやり方を「理解」するのは難しい場合があり、SOAP サービスを使用していたときに行ってきたことすべてに反する可能性がありますが、これらの原則を心に留めておくことが重要です。

理論的には、URL はリソースを記述し、使用可能な操作は GET (読み取り)、POST (作成)、PUT (作成または更新)、DELETE (削除) によってのみ実行されます。

編集: 各動詞が何にマップされるべきかについて私を修正してくれた marxidad に感謝します。

于 2009-03-30T03:25:01.090 に答える
3

上記の投稿で指摘されたコメントに加えて、構造を少し変更してもまったく問題ないと思います。(ただし、上記で指摘したように、データの更新に GET を使用しないでください)

CMS を例にとると、多くの場合、次の構造が表示されます。

{controller}/{id}/{action}
または
pages/about_the_company (display アクションがデフォルトのアクションです)
pages/about_the_company/edit(GET は編集ページを表示し、POST は更新を実行します)

もちろん、CMS ではコントローラーがデフォルトで設定されるpagesため、URL はさらに短くなります。

于 2009-03-30T07:03:29.877 に答える
1

RESTは、クリーンなURIを持つことではなく、HTTPメソッドGET、POST、PUT、およびDELETEに正しいセマンティクスを付加することです。

GETは安全なべき等操作のみ、POSTは作成または処理、PUTは既存のリソースの更新、DELETEはリソースの削除（うーん）を行う必要があります。

必要に応じて、RESTfulを開始しながら、多くの「？」および「＆」パラメーターを含む醜いURIを使用できます。

URIについてですが、2番目のオプションは問題ないように見えるかもしれませんが、英語以外の言語を使用して「プレーン英語」を書く方法です。そもそも良いアイデアに聞こえるかもしれませんが、URIを読みやすくすることの背後にある主なアイデアは、クライアントがURIを操作して、新しい機能を発見できることです。そのため、サイト/アプリケーションのツリー構造をURIに保持することをお勧めします。

このトピックの詳細については、UIとしてのURLに関するJacobNielsenのアラートボックスを参照してください。

于 2009-03-30T07:21:26.963 に答える
0

「{car-rego}/{controller}/{action}/{data etc}」のような URI 命名構造を定義すると、API は REST ではなくなります。これは単に RPC です。URI または URI 命名規則を REST API の一部として定義することはできません。RESTful アーキテクチャの制約の 1 つに直接違反しています。

詳細については、 http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-drivenを参照してください。

于 2009-07-20T22:42:10.480 に答える