REST API、HTTPステータスコードと結果コード

Question

これは、技術的な問題よりも「哲学的な」問題です。

あなたにメッセージがあり、このメッセージにアクセスすることが許可されている（または許可されていない）ユーザーがいるとします。 のは、ここでは、エンドポイントであろうと我々が行うためのAPIを持っていると仮定しましょう：

• /メッセージ/（id_message）/許可/（USER_ID）
• /メッセージ/（id_message）/（USER_ID）/禁止

ここで、HTTPステータスコードに加えて、result_codeというフィールドがあり、コード内で何が起こったかを正確に反映しているとします。

最初にユーザーを許可するとします。このメソッドのHTTPステータスコードは200で、result_codeが20であるとしましょう。

このメソッドをもう一度呼び出すと、HTTPステータスコード、result_codeとなる理由とその理由は何ですか？

Answer 1

確かにこれは哲学的な質問ではなく、標準が言うことと、これらの基準に従うことの本当の利点についてのものです。

HTTPは、GET、PUT、およびDELETE操作をidempotentに指定します。これは、コールを繰り返しても同じ効果が必要であることを意味します。

メッセージが失われる可能性があり、発信者がそれを処理する方法が必要であるため、これらの操作が偶発的になることは重要です。 RESTにはトランザクションが存在しないため、冪等の操作を繰り返すことで、最初の呼び出しに影響があるかどうかが呼び出し側に不明な場合に実行されます。あなたの例では、ユーザーを2回許可するのと同じようにする必要があります。その方法では複数の同一のリクエストをサーバに意図された効果は、単一のそのような要求の効果と同じである場合

要求方法が「冪等」と考えられる次のよう

RFC7231は冪等性を定義します。 [...]クライアントがサーバーの応答を読み取ることができる前に通信障害が発生した場合、要求を自動的に繰り返すことができるため、偶発的な方法が区別されます。 [...]それは、応答が異なるかもしれないけれども、元の要求が成功したとしても、要求を繰り返すことが意図された同じ効果を持つことを知っています。

サーバ側（メイン）エフェクトは同じである必要があります。 RFCは、応答が異なることを可能にします。特にDELETEの場合、正常に削除されると通常204 No Contentとなり、削除が繰り返されると404 Not Foundとなるため、これがよく発生します。

レスポンスは同一である必要はありませんが、そうであれば役立ちます。これにより、クライアントロジックが簡素化されます。クライアントは、繰り返し呼び出しが同じ効果を持つと仮定して、同じコードを使用してそれを処理できるはずです。 204または404のいずれかを返すDELETEの前述の例外は、（サーバーロジックを簡略化するため）非常に一般的です。その他の例外はまれであり、その理由がある場合にのみ作成する必要があります。

POSTおよびPATCH操作は、厳密に言えば、冪等である必要はありません。特にPATCHを使うと役立つかもしれません。

POST操作は、冪等ではありません。または逆の場合：冪等ができない操作がある場合は、POST操作でなければなりません。規格やRESTといえば

：あなたが言及した目的のためのRESTリソースではなく、次のようになります。

GET /messages/{messageId}/allowed-users 

は、許可されたユーザーのリストを返します。リストを表すリソースには、複数の名前が付けられています（messagesではなく、message）。

PUT /messages/{messageId}/allowed-users/{userId} 

許可されたユーザーのリストに新しいユーザーを追加します。

DELETE /messages/{messageId}/allowed-users/{userId} 

上記の権利を無効にします。

これらの操作はすべて冪等でなければなりません。 POST操作を使用

は、次のようになります。

POST /messages/{messageId}/allowed-users 

{ 
    "userId": "1324" 
} 

POSTは、リストのようなリソースに新しい要素を追加します。あなたはこの偶像崇拝をする必要はありませんが、私はこの場合にはお勧めです。

追加の結果コードをヘッダーまたは結果オブジェクトとして返すことができます。ちょうどあなたが言及したとおり。しかし、もしあなたが好きなら、既にそれについて細かく考えている人々がいて、problem-detailを思いついた。