0

私はRESTを見始めたばかりで、2つの表現の基本的な違いは何であるか疑問に思いました。最初のものは私にはかなり見栄えがよく、2番目のものはいくつかの属性値を渡す必要がありますが、基礎となるロジックはほぼ同じものに沸騰しているようです（私は間違っている可能性があります）

http://url/category/category_id/item_id

と

http://url/category?category_id={12}&item_id={12334}
4

3 に答える 3

1

エージェントがリソース構造について推論できるようにする必要があります。

  • URLに基​​づいて、および
  • リソースのリクエストによって返されたリンクに基づいています。

2番目の表現の問題は、実際の構造/階層がなく、順序付けされていないキーと値のセットと見なすことができることです。

于 2009-11-22T01:32:39.220 に答える
1

タグのボタンをクリックするrestful-urlと、このサイトから適切なリンクが表示され、これら 2 つのスタイルの違いが説明されます。

異なるファインダー「メソッド」でRESTリソースを取得する方法は?

于 2009-11-22T01:33:34.927 に答える
1

REST とは何かについて、いくつかの根本的な誤解の下で働いていると思います。

リソースへのアクセスに使用される URL は実際には詳細であり、実際にはクライアントにとって重要ではありません。URLは、REST の信条の 1 つであるHATEAOS 原則に従っている場合、クライアントによって実際に「発見」される必要があります。

どちらの URLも最終的に公開するリソースを表すことができますが、私が言うように、これは実際には詳細であり、多くの場合、公開する URL の好みに帰着します。HATEOAS のポイントは、既存のサービスに対して動作するクライアントに影響を与えることなく、リソースへのアクセスに使用される URL を自由に変更できるようにすることです。

次の URL は、サービスを真に RESTful にするいくつかのプロパティを理解するのに役立ちます。

[免責事項: HATEAOS が REST の原則であるからといって、簡単に実行できるわけではありません。Web 上のサービスのほとんどは、この原則に厳密に従っていないことがわかります。これは、URL テンプレートでいっぱいのドキュメントからも明らかです。理想的な世界でサービスを文書化する方法ではありません。本当にRESTfulなサービスとクライアントの良い例を見つけるのに苦労しています...]

于 2009-11-22T01:35:09.257 に答える