URLにクエリパラメータとしてURLを埋め込むことは、許容できるREST API設計パターンですか？
リソース指向のWebサービスをいくつか設計しています。
サービスBは、サービスAがその応答を作成するときに使用するサービスBのリソースへの参照を渡して、サービスAを呼び出すことができる必要があります。たぶん、サービスAは以前の対話からのサービスBのリソースについてすでにある程度の知識を持っています。
例えば.
GET http://serviceA.com/resource/123?widget=http://serviceB.com/widget/456
（明らかに、クエリパラメータ「ウィジェット」は適切にエンコードする必要があります）
私は実際にこのようなことの例をほとんど見ていません。あなたは時々それをウェブ上で見る。例は、GoogleのリダイレクトURIですOAuth（ https://developers.google.com/identity/protocols/OAuth2WebServer#formingtheurl ）
サービスBのリソースに関する知識をサービスAに組み込むのがより一般的であるため、代わりに次のような呼び出しを行います。
GET http://serviceA.com/resource/123?widget=456
これは、リソース指向の設計原則を破るようです。
クエリパラメータとしてURLを埋め込むことは適切な設計アプローチですか、それとも問題がありますか？
明らかに、URLの長さに制限があるユーザーエージェントで、URLの長さに問題が生じる可能性があります。そして、それはちょっと醜く見えます。しかし、他にマイナス面はありますか？なぜもっと使われないのですか？それともそうですか？それは、ほとんどのRESTベースのAPI設計が本当にRESTful（リソース指向）ではないためです。これは、それらが悪いとも言えません（ http://www.intridea.com/blog/2010/4/29/rest-isnt-what-you-think-it-is ）
これは、私の考えでは、URLパラメータの使用方法に依存します。 操作する必要がある実際のデータとしてURLを渡すことは問題ありません。
RESTサービスがWebブックマークを処理することを想像してください。これは、メタデータをブックマーク（たとえば、追加された日付、アイコンなど）に関連付けると仮定します。 REST Canon によるリクエスト特定のブックマークについてそのようなデータを要求すると、GETリクエストとなり、ブックマークのURLをパラメーターとして渡す必要があります。
一方、otherの側面を制御するためにURL運搬パラメーターを使用することは、おそらくお勧めできません。例えば。適切に設計されたREST APIのパラメーターの中で&redirect=http://...のようなものを期待することはできません。（OAuthはnota REST APIです。）
これは、クライアントがリクエストで適用した Granovetter導入演算子 の単純なケースのようです-リクエストを受信するリソースは、参照される特定の外部リソースの事前の知識を必要としません（互換動作）、および参照されている外部リソースがリクエストのサブジェクトまたはオブジェクトとして扱われている限り、RESTfulスタイルから逸脱していません。
ここで、Aliceはクライアント、Bobはリクエストを受信するリソース、Carolはリクエストで参照される外部リソースです。ボブは、それらを接続するエッジの欠如によって証明されるように、キャロルについての事前の特定の知識を持っていません。 fooは、単に任意のメッセージのデフォルト メタ構文変数 です。