安心なPOST APIは、リクエストボディパラメータに基づいてAPIレスポンスで2つの異なるリソースを返すことができますか？

Question

私たちは、商品の買い手と売り手を結ぶウェブサイトを持っています。

私たちはPOST APIを設計して、任意の売り手製品の購入者の関心を引くことができます。ウリとリクエストボディがどのように見えるAPI：私たちは、データベースにこの情報を保存しますので、

/api/lead/ 
{ 
    "name":"xyz", 
    "mobile": "00984343", 
    "stockid":4 
} 

APIはPOSTです。

「stockidは」私たちのプレミアム顧客に属する株式であれば、現在、APIは、APIレスポンスボディに売り手の詳細を送り返す：

{ 
    "sellername":"abc", 
    "sellermobile":"75654647", 
    "selleraddress": "faje street, curl" 
} 

「stockidは」私たちの通常の顧客に属する株式の場合は、API APIレスポンスのボディに戻って、その製品の完全な詳細を送信する（と売り手の詳細を返送しないでください）

{ 
    "description": "good 2nd hand mobile", 
    "purchasedate": "24 july,2017", 
    "purchaseprice": "10000" 
} 

同じPOST APIはバックリソースの異なる2種類（1売り手の詳細で、他の在庫の詳細である）を送信しています株式idに基づいて

このようにAPIを設計するのは安心ですか？つまり、POST APIはリクエストボディパラメータに基づいて複数のタイプのレスポンスを返すのですか？

Answer 1

この練習には疑問があります。個人的に私はそれをしません。

提案1：正常な顧客のための製品の詳細と製品の詳細との販売者の詳細、応答の豊かな形としての詳細。これにより、両方の応答がほとんど一貫しており、必要な機能が残っています。

EDIT：私は考えました。

提案2：これらの応答は基本的に異なるため、異なるリソースによって返される可能性があります。その場合、POST中にデータを返さないでください。idを使用してapi/seller/{stockid}とapi/product/{stockid}などの応答を返すか、idが特定のリソースに対して無効であればNo contentを呼び出してください。欠点は、多くの呼び出しを行う必要があり、アーキテクチャを複雑にします。

提案3：全く異なる応答オブジェクトを避けるために、クライアントが混乱を招き、クライアントがそれらをマップするのが難しくなるように、いくつかの "type"プロパティとオブジェクトを内部に持つラッパーオブジェクトを使用します。次のようなものがあります。

{ 
    "type" : "premium", 
    "data" : { 
    "sellername":"abc", 
    "sellermobile":"75654647", 
    "selleraddress": "faje street, curl" 
    } 
} 

完全ではありませんが、私の意見では2つの全く異なる応答よりも優れています。