RESTベストプラクティスコンテキストパラメータを使用したGET

Question

我々は識別子でリソースをプルする一連のRESTサービスを提供していますが、最近公開パラメータを渡して監査を保存することを義務づけています。今

何に使用されるように...

GET entity/{id} 

が何かのように変身...

GET entity/{id}?requestName=&requestingOrganization=&reasonForUse=&verificationMethod=&otherAuditDisclosureProperties.... 

entityの状態が変化し、しかし、我々は、追加を監査しなければならない、まだ冪等ではありませんそれを提供するために各コールの情報

代わりにボディを構築することが考えられましたが、それはGETにとっては適切ではないようでした。これは、クエリ/フィルタリングの意図がないクエリパラメータを使用する第2の手法です。これらの付加的なパラメータは、要求時点で捕捉された真のコンテキスト情報である。これらは、SOAP本体の外部にあるSOAP呼び出し内のSAML属性と同等です（これにより、可能なヘッダー属性と考えることができます）。

この情報は中継されるため、提供される認証トークンは、コンテキストを実際に呼び出すサービスユーザのものであり、実際のものではありません。元の呼び出し元のIDは、信頼フレームワークの周囲で暗黙的に信頼されています。

どのようにこの動詞/パスを定義しますか？

Answer 1

カスタムヘッダー：vnd.mycompany.myheader;必要なすべてのパラメータを解析可能な形式（name1=value1; name2=value2）に置きます。クエリ文字列から無駄を取り除きます。私はあなたが提供する多くの労力を必要とし、そのような主観的な情報については、APIの利用者を求めているシナリオを想像することはできません

オフトピック応答

（それはリクエストごとに変更されるように）クライアントに価値を提供しません。それは内部使用のためだけです。最も可能性の高い結果は、クライアントがそれらの値をハードコーディングし、すべての要求でそれらを繰り返すことです。

クライアントが内部の場合、クライアントがAPIを使用する理由を理解できるように、Sleuthなどの複数のサービスにまたがるリクエストを相互に関連付ける方法を探しているかもしれません。

クライアントが外部の場合は、開発者のアンケートや個人的なインタビューを考えてください。私は、あなたが最初にあなたのAPIコミュニティを育てて、それらの人々に到達し、彼らがあなたのAPIをどのように、なぜ使用するのかを理解することを提案します。

Answer 2

私はDaniel Cerecedoに同意します。適切な方法は、情報をリクエストヘッダーの一部として追加することです。 一般的な情報はhttps://www.w3.org/Protocols/HTTP/HTRQ_Headers.html です。実装はプログラミング言語によって異なります。