15

jsonデータを返すPHPアプリケーション用のRESTfulAPIのカスタム実装があり、操作のステータス、つまりリクエストに失敗があったかどうかを伝えるために、（非常にtiny）文字列としてのjsonオブジェクト。送信された実際のデータをいじることなく、応答を送信してクライアント側で簡単に取得できるため、これはうまく機能します。

問題は、この方法を使用することで私が気付いていないかもしれない欠点はありますか？アプリケーションがカスタムhttpヘッダーを設定することはあまり一般的ではないように思われるので、それが悪い習慣なのか、それとも悪い「味」なのか疑問に思います。

4

1 に答える 1

14

これは興味深い質問です。問題になる理由はないはずですが、いくつかの点を考慮に入れる必要があります。

  1. ヘッダーは、アプリケーションに固有である必要があります。今だけでなく、永遠に。接頭辞を付けていることを確認する必要がありますX-MyApplication-Foo: Bar。これを行わないと、将来的に競合が発生する可能性があります。

  2. ファイアウォールは、未知のHTTPヘッダーのフィルタリングに（まれに）少し熱心になることがあります。これは問題にはならないはずですが、覚えておくべきことがあります。

  3. 古いブラウザは、最新のブラウザよりもヘッダーフィールドサイズの制限が小さいため、できるだけ多くのブラウザでテストする必要があります。

標準のHTTPエラーコードを使用できない理由はありますか？スタックトレースやその他の有用なデバッグ情報を提供したい場合があることは理解していますが、エラーが発生した場合は、通常の「結果」JSONデータではなく、エラー情報を含むJSONBLOBを返すだけではないでしょうか。HTTPエラーコードに基づいて違いを簡単に検出し、2つのケースを異なる方法で処理できます。

提案されたアプローチに私が懸念している理由は、ヘッダーがブラウザーの動作を変更または引き起こすために使用されているためです。ヘッダーはデータストレージメカニズムを目的としたものではありません。

擬似コードの例：

switch(httpResponseCode)
{
    case 200:
        parseResult(json);
        break;
    case 403:
        parseForbidden(json);
        break;
    case 500:
        parseServerError(json);
        break;
    default:
        // bad response code, handle appropriately
}
于 2012-06-29T15:08:09.233 に答える