9

経験豊富なWebサービスのベテランの多くが、必須パラメーターが必要な場所でRESTfulURIを設計するための最良の方法についてコメントできるかどうかを調べています。適切な例として、データを要求するURIを設計したいと思います。

example.com/request/distribution

ただし、私の理解では、より多くのデータがより高いレベルで返され、より具体的なURIキーワードを適用するとより詳細なデータが返されるというアプローチですが、私の場合、そのためには少なくとも3つの値が必要です。これらの3つの値は、日付値、アカウント値、および独自の配布コード値になります。例えば：

example.com/request/distribution?acct=123&date=20030102&distcode=1A;1B;1C

それは「RESTful」URLと見なされますか、それとももっと意味のあるより良いアプローチがありますか？どんな入力でも大歓迎です。

ところで、Pythonは最適な言語です。ありがとう！

4

4 に答える 4

5

URI仕様は、RESTアーキテクチャスタイルによってガイドされているため、URIは、定義上、それ自体が「unRESTful」になることはできません。URIの使用方法は、次の方法でRESTスタイルに違反する可能性があります。

  1. 「クライアントサーバー」制約に従わない。たとえば、WebSocketを使用してサーバープッシュを実装します。
  2. 「リソースの識別」制約に従わない。たとえば、URIの一部を使用して、リソースの識別に固執するのではなく、制御データまたはリソースメタデータを指定したり、URI以外のメカニズム（セッション状態やその他の帯域外メカニズムなど）を介してリソースを識別したりします。
  3. 「表現によるリソースの操作」の制約に従わない。たとえば、URIのクエリ文字列部分を使用して状態を転送します。
  4. 「自己記述的メッセージ」の制約に従わない。たとえば、HTTP GETを使用して状態を変更したり、Content-Typeが「text/html」のJSONを転送したりします。
  5. 「アプリケーション状態のエンジンとしてのハイパーメディア」制約に従わない。たとえば、フォローするユーザーエージェントのハイパーリンクを提供するのではなく、帯域外の知識を使用してハイパーリンクを構築すると想定します。
  6. 「階層化システム」の制約に従わず、サーバーの動作の内部に関する詳細をクライアントに知らせるように要求します（特に、クライアントに要求でそれらを提供するように要求します）。

上記のどれも必ずしも悪い選択ではありません。これらは、特定のアーキテクチャプロパティ（効率やセキュリティなど）を促進するため、システムに最適な選択肢となる可能性があります。それらはRESTスタイルの一部ではありません。

リソースが複数の必須セグメントによって識別されるという事実は、URIの設計の一部です。アントンが指摘しているように、との間の選択はexample.com/request/distribution?acct=123&date=20030102&distcode=1A;1B;1C、example.com/accounts/123/distributions/20030102/1A;1B;1C純粋にデータ設計の1つであり、URIレイヤー自体の問題ではありません。たとえば、前者へのPUT、POST、またはDELETE要求への応答に問題はありません。どちらかへのリンクをたどることができなかったクライアントは、壊れていると見なされます。ハイパーメディア応答以外の手段でどちらかがクライアントに利用可能になることを期待していたシステムは、「RESTfulではない」と見なされます。

于 2012-07-09T00:59:02.713 に答える
3

URIではなく、最初にリソースの観点からRESTfulAPIを作成することをお勧めします。それは、たとえば、選択した言語よりも、データ設計と関係があります。

たとえば、配布リソースがあります。WebベースのAPIで表現する必要があるため、適切な一意のリソース識別子（URI）が必要です。シンプルで読みやすく、変更される可能性が低い必要があります。これはまともな例です：

http://example.com/api/distribution/<some_unique_id>

URIにさらに多くのものと階層を配置する前に、よく考えてください。

データモデルや認証スキームの進化に合わせてURIを変更する必要はありません。URIを変更することは、APIを使用するあなたと開発者にとってクールで苦痛です。したがって、認証をバックエンドに渡す必要がある場合は、おそらくGETパラメーターまたはHTTPヘッダーを使用する必要があります（たとえば、AWS S3 APIでは両方が許可されます）。

GETパラメータ（たとえば）に入れすぎるhttp://example.com/api/distribution/?id=<some_unique_id>のは悪い考えのように思えるかもしれませんが、APIドキュメントにアクセスして最新の状態に保つ限り、IMOは実際には重要ではありません[0]。

[0]更新：少なくとも読み取り専用APIの場合。CRUD APIの場合、@ danielが指摘しているように、上記の最初の例のようにエンドポイントがあると便利です。/api/distribution/<id>このように、で個々のリソースに対してGET、PUT、DELETEを有効にし、POSTを有効に/api/distributionして新しいディストリビューションを作成することにより、HTTPメソッドをうまく使用できます。

答えを調査しているときに、RESTful APIに関する優れたプレゼンテーションを見つけました：HTTPインターフェイスとRESTfulWebサービスの設計。

于 2012-07-08T23:07:53.850 に答える
0

RESTfulな方法は、データをリクエストのパラメーターではなく、リソースとして表すことです。

example.com/distribution/123/20030102/1A;1B;1C
于 2012-07-08T21:56:19.040 に答える
-1

RESTfulについて考えるとき、ほとんどの場合、CRUDについても考える必要があります。

example.com/request/distribution?acct=123&date=20030102&distcode=1A;1B;1C

GET-Requestが何かを表示するのは問題ありません（CRUDのR）。

しかし、CUD-PartsにはどのURLを考慮しますか？

于 2012-07-08T21:29:55.500 に答える