6

私は、かなり広まっていることがわかった慣習に出くわしました。これに名前を付けたウェブページも見つけましたが、名前を忘れてしまい、グーグルでそのページを見つけることができなくなりました。

実際には、RESTサービスからのすべてのJSON応答は次の構造を持つ必要があります。

{
    "status": "ok",
    "data": { ... }
}

またはエラーの場合：

{
    "status": "error",
    "message": "Something went wrong"
}

私の質問：JSONでこのような「ステータス」プロパティが必要な理由は何ですか？私の意見では、それがHTTPステータスコードの目的です。

RESTは、クライアントとサーバー間のHTTP通信手段を使用します。たとえば、削除には「DELETE」動詞を使用する必要があります。同様に、リソースが見つからない場合などは404を使用する必要があります。したがって、その考えに沿って、エラーの場合はHTTPステータスで適切にエンコードする必要があります。

エラーの場合にHTTP200ステータスコードを返し、代わりにJSONでエラーを発生させる特定の理由はありますか？応答を処理するときに、javascriptの条件分岐がより複雑になるようです。

アプリケーションに特定のURLにリダイレクトするように指示するために、ステータスが「リダイレクト」になる場合があることがわかりました。ただし、適切なHTTPステータスコードが使用された場合、ブラウザは「無料」でリダイレクトを実行し、閲覧履歴を適切に維持します。

私は主にあなたからの2つの可能な答えを想像します：

  • それぞれが好きなアプローチを持つ2つの喧嘩コミュニティがあります（HTTPステータスを常に使用するのかHTTPステータスを使用しないのか）
  • または、重要なポイントが欠落しているため、HTTPステータスを使用する必要がある場合もありますが、HTTPステータスが適合せず、「ステータス」JSONプロパティが機能する場合もあります。
4

3 に答える 3

4

あなたが正しいです。あなたが見ているのは、RESTを正しく行っていない人々の副作用だと思います。または、RESTをまったく実行していません。RESTの使用は、適切に設計されたアプリケーションの前提条件ではありません。WebアプリがRESTフルでなければならないという規則はありません。

一方、エラー状態の場合、アプリは200コードを返したいが、ビジネスロジックの失敗を表すエラーを返したい場合があります。HTTPエラーコードは、アプリケーションのビジネスエラーのセマンティクスと常に一致するとは限りません。

于 2012-07-11T13:09:03.967 に答える
3

ここでは、2つの異なるレイヤーを混合しています。

  • HTTPは、（高レベルの）接続を確立してデータを転送するためのものです。したがって、HTTPステータスコードは、接続が確立されたかどうか、どのように確立されたか、または接続が確立されなかった理由を通知します。接続が成功すると、HTTPリクエストの本文に何か（XML、JSONなど）が含まれる可能性があるため、これらのステータスコードで一般的な意味を定義する必要があります。応答の正確性やタイプ（エラーメッセージやデータなど）については通知されません。

  • データの交換にJSONを使用する場合は、プロパティを省略できstatusますが、要求したオブジェクトまたは1つのプロパティを読み取るだけでエラーメッセージが含まれているかどうかがわかっている場合は、JSONを解析する方が簡単です。

したがって、はい、200ステータスコードを返し、 "status": "error"JSONにプロパティを含めることは完全に正常です。

于 2012-07-11T13:34:22.473 に答える
2

HTTPステータスコードは、ロードバランサー、プロキシ、キャッシュ、ファイアウォールなど、さまざまな原因で発生する可能性があります。これらのいずれも、JSON出力を完全に破壊しない限り、JSON出力を変更することはなく、エラーとして扱うこともできます。

結論：JSONを介して行う方が信頼性が高くなります。

于 2012-07-11T13:13:20.667 に答える