1

RESTful API エンドポイントを設計する方法で競合している 2 人の開発者がいます。基本的に、Facebook 製品を手元に持っているとしましょう。投稿用のテーブルが 1 つあります。

最初の開発者は次のような意見を述べます

  • テクニカル ストレージごとではなく、製品ごとにエンドポイントを分離する必要があります。そのために、ユーザーの facebook 投稿と他の facebook 投稿用のエンドポイントを用意します。

/v1/wall/mypost

/v1/wall/other

  • そのようにするために、異なる結果を返す可能性のある各製品を構成することができます

2 番目の開発者は同意しません。次の意見を述べてください。

  • このままだと無限エンドになります。/wall/someone、になります/wall/sometwo。

  • 単一のエンドポイントが必要であり、それをクエリの一部にするだけです。元。/wall?user=someone、/wall?user=sometwo

  • エンドポイントは技術スキーマのように見える必要があり、同じ結果を返します。コードのメンテナンスでより多くの仕事をするために分離する必要があるのはなぜですか。

エンドポイントを設計するための良い方法は何ですか? 製品ごとにエンドポイントにする必要がありますか? それともスキーマによるものですか？

4

2 に答える 2

0

あなたが話しているこれらの「エンドポイント」とは何ですか? それが SOAP 用語です。RESTful Web サービスは、URL によって一意に識別される「リソース」に関して定義されます。

通常、リソースはドメイン モデル内のエンティティ (ユーザーなど) を表します。エンティティの ID は通常、URL 内のパス要素 (JAX-RS などのほとんどの REST ライブラリの専門用語では「パス パラメーター」) として使用されます。クエリ パラメーターは、サーバー側で結果を並べ替え/フィルター処理するためにのみ使用する必要があります。

あなたの最初の開発者は正しいことに近づいています。

于 2013-09-19T22:08:16.033 に答える