1

次のシナリオに適した方法で残りのエンドポイントを設計したいと考えています。

グループがあります。各グループにはメンバーがいます。メンバーになるには、グループ管理者の承認が必要です。管理者が拒否した場合、ユーザーはグループのメンバーになることはできません。

このシナリオに対処するために、次のエンドポイントがあります。

  1. ユーザーがグループに参加したとき POST /projects/api/v1/projects/{project id}/members/{member id}

  2. 入会 PUT /groups/api/v1/groups/{group id}/members/{member id}/approve承認のため 入会承認のため

ただし、メンバーシップを拒否するための適切なエンドポイントを決定するのに苦労しています。使うべきか

PUT   /projects/api/v1/projects/{project id}/members/{member id}/reject

また

DELETE  /projects/api/v1/projects/{project id}/members/{member id}
4

3 に答える 3

5

率直に言えば、URI の使い方が間違っています。「承認」などの「アクション」は URI の一部であってはなりません。

複数のリスト

これを行う「明白な」方法は、グループが承認されたメンバーと受け入れを待っているメンバーの両方のリストを持つことだと思います。ユーザーが追加されることを望む場合、彼はPOST /groups/{group id}/waitlist/{user id}. これにより、管理者は非常に簡単に拒否できますDELETE /groups/{group id}/wait_list/{user id}。管理者が承認したい場合は、POST /groups/{group id}/users/{user id}.

ここで見られる問題の 1 つは、ユーザーが「承認済みユーザー」リストと「承認待ちユーザー」リストの両方に含まれていることがわかっていることです。このユーザー リストをどのように正確に管理するかによっては、問題にならない場合があります。ただし、ユーザーがこれらのリストのいずれかにのみ含まれることを希望する場合は、承認後にそのユーザーを待機リストから削除する必要があります。

一見すると簡単なこと。2つのオプションが思い浮かびます.1つは、ユーザーを承認するときに、ユーザーを「ユーザー」リストに追加することにより、サーバーが「待機リスト」からも削除することです。これは少し汚いことです。POST はそのような副作用を持つことを意図していません。つまり、クライアント (管理者) が 2 番目の要求を行う必要があります。

パッチの人々！

もちろん、PATCH メソッドを使用すれば、これはすべてはるかに簡単になります。グループには、このグループでのステータスと対になったユーザーのリストを含めることができます。グループに追加されたい場合は、 のようにリクエストしますPATCH /group/{group id}/users/ {'user id': 666, 'status':'request access'}。管理者が承認/拒否する場合、フィールドを更新するだけで、ほぼ同じ要求を行いstatusます。

ここでの追加の利点は、管理者がユーザーのステータスを「拒否」、「取り消し」、「一時停止」などに設定でき、特に何もする必要がないことです。サーバーがこれらの選択を検証していることを確認する必要はありますが、そうしないと、あらゆる種類のばかげたことになります. ユーザーが最初にアクセス許可を要求しなくても、管理者がユーザーを直接追加できるようにすることもできます。管理者が誰かをモデレーターとしてすばやく追加したい場合など。

于 2014-06-15T20:25:05.807 に答える
0

既存のオブジェクト リソースを変更する (ステータスも変更する) 必要がある場合は、 を使用する必要がありますPUT。既存のオブジェクト リソースを上書きし、200 の成功ステータスを返します。POSTサーバーにデータを送信して処理する場合に推奨されます。さらに、条件付き動作を適用して正確なリソースを選択するには、If-Matchヘッダーを使用できます。

ここでより良いガイドを見つけてください。

于 2014-06-15T12:41:09.293 に答える
-1

POSTを使用します。その後、そのメンバーをそのグループの拒否状態にすることができます。そうしないと、リソースが削除された場合、メンバーは何度も再申請できると思います。

説明する：

POST   /projects/api/v1/projects/1/members

201, CREATED

{
    id: 1234
    member: 'Tom'
    status: 'pending'
    links: [{
            rel:  'self',
            method: 'GET',
            href: '/projects/api/v1/projects/1/members/1234'
        },{
            rel:  'member',
            method: 'GET',
            href: '/projects/api/v1/members/4321'
        },{
            rel:  'reject',
            method: 'POST',
            href: '/projects/api/v1/projects/1/members/1234/reject'
        },{
            rel:  'accept',
            method: 'POST',
            href: '/projects/api/v1/projects/1/members/1234/accept'
        }]
}


POST   /projects/api/v1/projects/1/members/1234/reject

204: No Content


GET   /projects/api/v1/projects/1/members/1234

200, OK

{
    id: 1234
    member: 'Tom'
    status: 'rejected'
    links: [{
            rel:  'self',
            method: 'GET',
            href: '/projects/api/v1/projects/1/members/1234'
        },{
            rel:  'member',
            method: 'GET',
            href: '/projects/api/v1/members/4321'
        },{
            rel:  'appeal',
            method: 'POST',
            href: '/projects/api/v1/projects/1/members/1234/appeal'
        }]
}

編集：もちろん、拒否および承認アクションリンクは、正しい権限を持つユーザーにのみ提供されます。

于 2014-06-15T12:01:47.313 に答える