3

リモートサーバーに対して実行される iOS アプリケーションを開発しており、その背後に別の開発者がいます。私たちが書いているプロジェクトと API ドラフトは初期段階にあります。

私たちが直面している問題は、HTTP/REST 仕様で記述された従来のステータス コードの量に満足できず、どのコードを取得すればよいかわからない場合があることです。

最小限のコンテキストを提供する例:

  1. サーバー側の検証エラー。Fx。クライアント側の検証は問題ありませんが、サーバー API が最近わずかに変更されたため、サーバーはそれが検証の問題であることを示す何かを返す必要があります。

  2. すでに存在するユーザーを登録しようとしています。SOトピックは、それに関する正確なポイントを提供しません。

  3. ユーザーが登録されており、パスワードの確認手順を完了せずにログインしようとしています。

ここで見られる 2 つの明白なアプローチ:

  1. 適切な従来のステータス コードが見つからなかった場合は、fx 400 エラーを使用します。これにより、JSON 応答からエラー テキスト メッセージを解析することができます。明らかに、このアプローチはクライアント側のコードに余分な複雑さをもたらします。

  2. 独自のサブコード システムを作成し、コード内でそれを利用します。これにはあまりにも多くの人為的な慣習が含まれており、あまりにも独断的で恣意的になる傾向があります。

そのようなケースの数が増えると感じているため、サーバーが返す JSON 応答にカスタム サブコードを導入することを検討しています (つまり、2 番目のアプローチを選択します)。

私がここで尋ねていること：

このような状況で推奨されるアプローチ、戦略、接着剤やハックは何ですか?

ステータス コードの REST/HTTP 規則に厳密に従うことから離れることの長所と短所は何ですか?

ありがとう！

4

3 に答える 3

4

検証の問題については、422 Unprocessable Entity (WebDAV; RFC 4918) を使用します。要求の形式は適切でしたが、セマンティック エラーのため従うことができませんでした。これは、不正な構文が原因でリクエストが失敗したのではなく、セマンティクスが原因で失敗したためです。

次に、通信するためにエラー形式を決定するだけでよいため、状況 1 で必須フィールドがある場合は、次のように 422 を返すことができます。

{
  "field": ["required"]
}

実際にはユーザー名の検証の問題であるため、2番目を検証の問題として扱います.422は次のとおりです。

{
  "username": ["conflict"]
}

3 番目は、403 Forbidden として扱います。認証ヘッダーを渡すことは役に立たず、資格情報を渡す以外のことを行うまで禁止されるためです。

oauth2のようなことを行って、人間が読める説明を返すことができます。これは、エラーをさらに明確にするために人々がコーディングできる定数であり、詳細情報の uri です。

{
  "error": "unfinished_registration",
  "error_description": "Must finish the user registration process", 
  "error_uri": "http://yourdocumentation.com"
}

注: どの http コードがどのような状況に対応するかについて、また、422 は WebDAV 拡張機能の一部であるため使用する必要があるかどうかについて、人々が意見を異にすることに気付くでしょう。彼らが意味するものに完全ではなく、一貫性があります。

于 2012-09-20T15:28:49.100 に答える
3

HTTP には「サブコード」のようなものはありません (Microsoft IIS は明らかに仕様に違反しており、むち打たれるべきです)。

適切なステータス コードがある場合は、それを使用します。一般的なステータス コードの価値が失われるため、「このステータス コードは私のアプリケーションではそれを意味する」とは言わないでください。独自のプロトコルを設計することもできます。

その後、ステータス コードのセマンティクスを改良する必要がある場合は、ヘッダーおよび/または本文を使用します。

于 2012-09-21T00:49:08.373 に答える
2

説明した使用例では、次のエラー コードを使用できます。

1) 400 不正なリクエスト

構文が正しくないため、サーバーは要求を理解できませんでした。クライアントは、変更なしでリクエストを繰り返すべきではありません。

2) 409 コンフリクト

リソースの現在の状態と競合するため、要求を完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。応答本文には十分な情報を含める必要があります

ユーザーが競合の原因を認識するための情報。理想的には、応答エンティティには、ユーザーまたはユーザー エージェントが問題を解決するのに十分な情報が含まれます。ただし、それは不可能な場合があり、必須ではありません。

競合は、PUT 要求への応答で発生する可能性が最も高くなります。たとえば、バージョニングが使用されていて、PUT されているエンティティに、以前の (サードパーティの) 要求によって行われたものと競合するリソースへの変更が含まれていた場合、サーバーは 409 応答を使用して、要求を完了できないことを示す可能性があります。 . この場合、応答エンティティには、応答の Content-Type によって定義された形式で、2 つのバージョン間の相違点のリストが含まれている可能性があります。

3) 401 権限がありません

リクエストにはユーザー認証が必要です。応答には、要求されたリソースに適用可能なチャレンジを含む WWW-Authenticate ヘッダー フィールド (セクション 14.47) を含める必要があります。クライアントは、適切な Authorization ヘッダー フィールド (セクション 14.8) を使用してリクエストを繰り返すことができます。リクエストに承認資格情報がすでに含まれている場合、401 応答は、それらの資格情報に対する承認が拒否されたことを示します。401 応答に前の応答と同じチャレンジが含まれており、ユーザー エージェントが少なくとも 1 回認証を試みている場合、応答で指定されたエンティティをユーザーに提示する必要があります。そのエンティティには関連する診断情報が含まれている可能性があるためです。HTTP アクセス認証については、「HTTP 認証: 基本およびダイジェスト アクセス認証」[43] で説明されています。

その他のユース ケースでは、状況が異なります。特定のエラーをエンコードする標準的な方法が本当にない場合は、おそらく 2 番を使用します。

于 2012-09-20T14:17:59.663 に答える