REST API：1つのAPIに複数の責任がありますか？

Question

私たちはログインしていない商品Webサイトを分類しましたが、他のユーザーがリストした製品を見ることができます。他のユーザーの詳細を表示するには、連絡先の詳細を入力する必要があります。ユーザーが正しい携帯番号を提供しているかどうかを確認するために、番号にOTPコードを送り返します。 APIの流れは次のようになります。

1）//ユーザーは、これは「stockId」と入力として「モバイル」）期待する（特定の株式の売り手の詳細を取得するために、フォームを記入するときにヒットするAPI：

POST /api/lead/ 
{ 
    "stockId":123, 
    "mobile":9890384328 
} 

APIのレスポンス "モバイル" はすでに検証された場合（応答コード：200）：

{ 
    "sellerName": "xyz", 
    "sellerMobile": "+123232312", 
    "sellerAddress": "21, park street, new york" 
} 

レスポンス "モバイル" はすでに検証されていない場合（応答コード：403）：

{ 
    "OTP verification required. OTP is sent to the mobile number." 
} 

OTPが正しいかどう

{ 
     "sellerName": "xyz", 
     "sellerMobile": "+123232312", 
     "sellerAddress": "21, park street, new york", 
     "otp": 1234 
} 

それが応答で販売者の詳細を送り返す：

2）ユーザーは、同じリードAPIを携帯で受信したOTPを再び要求を送り返します。 OTPが提供する場合は正しくない、応答は次のとおりです。

{ 
    "Incorrect OTP." 
} 

私は、このAPIの設計にいくつかの問題を参照してください：このAPIは、OTPを戻って、売り手の詳細を戻っすなわち作業の多くを行っている

1. OTP関連の機能を他のAPIに簡単に壊すことができます。たとえばOTP、すなわちGET/api/otp /を生成する1つのAPI、OTP、すなわちPOST api/verifyotp /を検証するための他のAPI。これにより、クライアントからのAPIコールの数が増加します。つまり、最初のクライアントがPOSTリードAPIを開始し、数が検証されない場合、クライアントはOTP APIにヒットします。 OTPによって検証するためには、verifyOTP apiを呼び出します。それが確認されると、Lead APIを呼び出して販売者の詳細を取得します。したがって、基本的には上記のアプローチでは4つのAPI呼び出しと2つのAPI呼び出しを行います。
2. これは、「RESTクライアントが単純な固定URLを通じてRESTアプリケーションに入る」というHATEOSの非適合です。将来のすべてのアクションは、サーバーから返されたリソース表現内で検出されます。

誰かがどのアプローチが良いとお考えですか？

Answer 1

簡易回答：なし。

という責任原則となります。

パブリックAPIで複数の責任を許容するということは、API「エンドポイント」がこれらの各側面の「正しい」実装に「派遣」する異なる責任を理解しなければならないことを意味します。または、二重責任APIの設計をにすると、その実装を提供することを一つだけ持ち、の実装を破損させることができます。

それ以上：責任が異なる場合、OK /エラーリターンコードの範囲は単純に複雑になります。それは単に「すべて」をより困難にします。テストを書くだけでなく、APIを使用するクライアントのためにも。あなたのケースでは

、ユーザーが行います。

• 使用/ APIを/鉛最初
• は "未検証" について語られる確認コードを取得するには
• 使用OTP生成API
• 特定のOTP APIを使用して確認コードを提出する
• さらに/ api/leadを使用する