RESTful APIで関係を管理する方法は？

Question

「Issues Tracking Application」のRESTfulサービスを作成して、RESTアーキテクチャを学習しています。 ITAにはユーザー、プロジェクト、問題、コメントがあることが多くの方に分かりました。

次のような関係は、次のとおりです。

• プロジェクトは、問題を持って、これらの問題は、特定のユーザーによって管理されています。
• 問題にはコメントがあり、特定のユーザーによって管理されています（投稿されたこともあります）。
• プロジェクトはユーザーによっても管理されます。

私はルートを構成する決定に固執しています。私はここに投稿しているテキストファイルにいくつかのルートを書きました。見て、改善を提案し、間違いを特定してください。

Models: 
    - User 
    - Project 
    - Issue 
    - Comment 

1. User 
    > Immediate Requirement 
    GET  api/users/    /* Authenticate, and then return list of all users */ 
    GET  api/users/:id    /* Authenticate, and return a particular user */ 
    POST  api/users/    /* Create a new user */ 
    PUT  api/users/:id    /* Authenticate, and update a particular user */ 
    > Add-on Requirement 
    GET  api/users/:id/projects/ /* Authenticate, and return list of projects of particular user */ 
    > Never Mind Requirement 
    DELETE api/users/    /* Authenticate, and delete all users */ 
    DELETE api/users/:id    /* Authenticate, and delete a particular user */ 

2. Project 
    > Immediate Requirement 
    GET  api/projects/    /* Authenticate, and then return list of all projects */ 
    GET  api/projects/:id   /* Authenticate, and return a particular project */ 
    POST  api/projects/    /* Authenticate, and create a new project */ 
    PUT  api/projects/:id   /* Authenticate, and update a particular project */ 
    > Add-on Requirement 
    GET  api/projects/:id/issues /* Authenticate, and return a list of issues of particular project */ 
    POST  api/projects/:id/issues /* Authenticate, and create new issue for particular project */ 
    DELETE api/projects/:id/issues /* Authenticate, and delete all issues of particular project */ 
    > Never Mind Requirement 
    DELETE api/projects/    /* Authenticate, and delete all projects */ 
    DELETE api/projects/:id   /* Authenticate, and delete a particular project */ 

3. Issue 
    > Immediate Requirement 
    GET  api/issues/    /* Authenticate, and then return list of all issues */ 
    GET  api/issues/:id   /* Authenticate, and return a particular issue */ 
    PUT  api/issues/:id   /* Authenticate, and update a particular issue */ 
    > Add-on Requirement 
    GET  api/issues/:id/comments /* Authenticate, and return a list of comments of particular issue */ 
    POST  api/issues/:id/comments /* Authenticate, and create a new comment for particular issue */ 
    DELETE api/issues/:id/comments /* Authenticate, and delete all comments of particular issue */ 
    > Never Mind Requirement 
    DELETE api/issues/    /* Authenticate, and delete all issues */ 
    DELETE api/issues/:id   /* Authenticate, and delete a particular issue */ 

4. Comment 
    > Immediate Requirement 
    GET  api/comments/    /* Authenticate, and then return list of all comments */ 
    GET  api/comments/:id   /* Authenticate, and return a particular comment */ 
    PUT  api/comments/:id   /* Authenticate, and update a particular comment */ 
    > Never Mind Requirement 
    DELETE api/comments/    /* Authenticate, and delete all comments */ 
    DELETE api/comments/:id   /* Authenticate, and delete a particular comment */ 

この投稿は、このアーキテクチャで最も重要で困難なことであるため、RESTを学習しようとしている多くのユーザーに役立ちます。

Answer 1

私はDELETE動詞についてコメントしたいと思います。すべてのレコードでPUTとDELETEを使用するのは悪い習慣です。

いくつかの場所のすべてのインスタンスでDELETEを使用しました。これはあなたの必要条件かもしれません。どちらの場合も選択肢はありませんが、それが絶対的な要件でない場合は、ベストプラクティスに従う方が良いです。

Answer 2

RESTはURI設計に制約を加えません。たとえば、次のURI api/issues/:id/commentsによって、唯一の重要な部分は:idです。それ以外のものは意見に基づくことができます。これは、RESTによってリンクを返送し、リンクにURIまたはURIテンプレートが含まれるため、クライアントは最初からURIを再構築する必要がないためです。これらのリンクにはリンク関係があり、クライアントはそのリンクを使用してリンクの内容や表示方法を確認します。したがって、URIは内部使用のためだけであり、HATEOAS constraintに従っているかどうかを文書化する必要はありません。別の参照：あなたは私に言わせればhttp://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

は、私は、階層的なものの上に平らなURI構造を好む：api/comments/?issue=:idと私はコレクションのURIの末尾に/を入れて使用しますが、それはちょうど私の個人的な好みです。