web-dev-qa-db-ja.com

http 401と409の間で選択

ユーザーのフォローとフォロー解除を行う2つのAPIがあります。

domain/uid/follow    (http POST)       to follow user
domain/uid/follow    (http DELETE)     to unfollow user

ユーザーをフォローし、httpコード200で応答します。ユーザーが再度フォローしようとすると（既にフォローされているユーザー）私は401で応答します。

質問：

1-401 Unauthorizedまたは409 Conflictで応答する必要がありますか？

2-ユーザーが誰かをフォローしておらず、フォローを解除しようとした場合も同様です。

編集：

単一のAPIを使用して切り替えませんfollow/unfollow動作。両方のアクションに2つの別個のAPIがあります。

エラーで応答する特別な理由はありません。ユーザーが2回フォローされていないことを確認するAPIの自動テストは、それが使用されている場所のみです。

designapi-design
13
Shaharyar

技術的には、使用するHTTPメソッドによって異なります。 PUTを使用することをお勧めします。使用した場合、この引数行は正常に機能します。

誰かが別のユーザーをフォローしたいが、すでにフォローしている場合は、まったく問題ありませんか？アンフォローについても同様です。したがって、は常に200を返します。

この動作はべき等と呼ばれます。詳細は この説明 を参照してください。

POSTを行う場合は、技術的にはHTTPの規則に従ってリソースを作成する必要があります。リソースの作成はべき等ではないので、インターフェースもそうではありません。その規則に従っている場合、二重のフォロー/フォロー解除リクエストでステータス409 Conflictまたは422 Unprocessable Entityを返す必要があります。 エラーレスポンスの本文で理由を詳細に説明することをお勧めします。それはあなたのAPI消費者を大いに助けます。

ただし、RFC 7231（HTTP 1.1）では、常にリソースを作成する必要はありません。したがって、べき等POSTも有効な解決策です。

注：401はUnauthorizedを意味します。つまり、リクエストが資格情報を提供しないか、提供された資格情報がinvalidです。ただし、フォロー/フォロー解除を実行する前に、資格情報の検証に成功したと想定しています。したがって、401で応答しても、そのような状況ではまったく意味がありません。 403 Forbiddenはかなりフェッチされており、あまり適切ではありません（ただし、401より優れています）。

42
marstato

ビジネスエラーをHTTPステータスコードに変換しないでください。ステータスコードは、ドメインやユーザー自体ではなく、HTTPクライアントによって読み取られることを目的としています。これら2つとの通信には、応答本文を使用します。メッセージを送信する必要がある場合は、応答本文で送信します。

フォローアップの作成 1

POST /domain/uid/follow HTTP/1.1
...
HTTP/1.1 201 Created
Date: Fri, 20 Dec 2017 14:30:00 GMT
Content-Type: application/json
Location: /domain/uid/follow/123456

フォローアップの複製 2

POST /domain/uid/follow HTTP/1.1
...
HTTP/1.1 409 Conflict
Date: Fri, 20 Dec 2017 14:30:00 GMT
Content-Type: application/json
Content-Length: 100
{"message":"already following Shaharyar!"}

カスタム応答ヘッダーも使用する場合があります。

MyApplication-error: AlreadyFollowingUserError

フォロー解除

2-ユーザーが誰かをフォローしておらず、フォローを解除しようとした場合も同様です。

この2番目のケースは少し異なります。

存在しないリソースを削除しようとしている場合

DELETE /domain/uid/follow HTTP/1.1
...
HTTP/1.1 404 Not Found
Date: Fri, 20 Dec 2017 14:30:00 GMT
Content-Type: application/json
Content-Length: 1000
MyApplication-error: ResourceNotFound
{"message":"resource not found"}

または@Kとして。 Alan Batesがコメントしました（Alanに感謝します）。要求したURIがまだ到達可能であればすぐに、操作をべき等にすることができます。

DELETE /domain/uid/follow HTTP/1.1
...
HTTP/1.1 204 No content
Date: Fri, 20 Dec 2017 14:30:00 GMT
Content-Type: application/json
Content-Length: 100

簡単にするために、204を選択しました。 200または202の可能性があります。

いずれにせよ、401 Unauthorized私たちのセキュリティサービスが別のことを言わない限り.

1：編集-理想的には、新しいリソースの作成後、新しいリソースの場所（uri）とステータスコード201で応答する必要があります

2：編集-ここでのステ​​ータスコードはメソッドによって異なります。 POST=の場合、新しいリソースを要求しています。すでに存在する場合、409の競合は発生します。要求が新しいリソースを作成する場合、201。PUTを送信する場合、200または204のいずれかがわかりました。しかし、べき等性はこれのすべてを簡素化できます

19
Laiv

Marstatoの回答に関する Willem Renzemaのコメントで言及されたRFC に基づいて、私はあなたのPOST新しいリソースを作成することは最もクリーンなアプローチだと思います。クライアントでそれらを検索する必要がない場合は、「domain/uid/following」などの単純なことを行います。次に、フォローを解除したい場合は、そのリソースを削除します。すでに存在する場合、303を返し、「フォロー」リソースを含む「Content-Location」ヘッダーを返します。

「フォロー」リソースを作成することの副次的な利点は、それを使用して、ユーザーがフォローしているもののリストを作成できることです。

2
JimmyJames