2

「solutions」テーブルにレコードを挿入するためのRESTAPIを設計しています。「ソリューション」には、solverID、problemIDがあります。私は2つの異なるデザインを念頭に置いています：

POST /solutions

そして、ソリューションのコンテンツとともにJSONでsolverIDとproblemIDを渡します。または、solverIDとproblemIDをURIに入れます。

POST /users/:solver_id/problems/:problem_id/solutions

どちらのデザインが良いですか？

4

3 に答える 3

1

リソースを一貫した階層で定義して、リソースを簡単に理解および予測できるようにすることをお勧めします。

これが質問を取得するためのURLだとしましょう-

GET     /users/{solverId}/problems/{problemId}

問題が{solverId}に属していることを明確に伝えています。

次のURLは、{solverId}によって解決された問題のすべての解決策を取得していることを明確に示しています。

GET     /users/{solverId}/problems/{problemId}/solutions

{problemId}の新しいソリューションを作成するには、に投稿します。

POST     /users/{solverId}/problems/{problemId}/solutions

特定のソリューションを取得するには、

GET     /users/{solverId}/problems/{problemId}/solutions/{solutionId}

パスとクエリでIDを使用する場合

リソースを識別するためにIDが確実に必要な場合は、パスでIDを使用します。上記のシナリオでは、ソリューションを一意に識別するために3つのIDがすべて必要であるため、それらすべてがパスに含まれている必要があります。

特定の日付範囲で指定されたソリューションを取得したい場合は、次を使用します。

GET     /users/{solverId}/problems/{problemId}/solutions?startDate={}&endDate={}

ここで、startDateとendDateはリソースを一意に識別できません。これらは、結果をフィルタリングするために使用されている単なるパラメーターです。

于 2013-03-18T17:17:43.363 に答える
1

最初のもので行きます。私はあなたのURLをできる限りクリーンでシンプルに保ちます. ここに私の頭の上のいくつかの他の例があります。構造全体についてはわかりません。

POST /solutions

GET /solutions?solverid=123  //query solutions by user

GET /users/555/problems      // problems for a given user
GET /users/555/solutions     // solutions for a given user

GET /problems/987/solutions  // solutions for a given problem
于 2013-03-14T23:42:08.507 に答える
0

ルートに認証が必要ない場合にのみルートにユーザー ID を含め、それ以外の場合は認証情報からユーザー ID を割り出すことができ、上記のルートは次のようになります。

POST /problems/:problem_id/solutions
于 2013-03-18T16:51:03.193 に答える