2

HTTP を介して公開された RESTful API があり、自然な方法で HTTP ステータス行 (ステータスコードと理由フレーズ) を使用して API の結果をクライアントに伝えます ( http://www.w3.org/Protocols/ rfc2616/rfc2616-sec6.html )。

たとえば、同時実行エラーのステータス行は次のとおりです。

HTTP/1.1 409 リソースが別のユーザーによって更新されました。リロードして、もう一度お試しください。

これらのメッセージは、API に対して構築されたアプリケーションのエンド ユーザーに表示されることが最近判明しました。つまり、メッセージをローカライズする必要があります。特にこれらのメッセージの非ASCII文字セットを考慮して、これがそのようなシナリオで受け入れられるアプローチなのか、それとも理由フレーズ（ステータスの説明）を低レベルのメッセージとその方法を作るコンテンツとしてのみ保持する必要があるのか​​ 疑問に思っていますユーザー画面を応答本文で渡す必要がありますか? 理由句の部分をローカライズすることを選択した場合、後で私たちを悩ませるものはありますか?

この場合、レスポンス ボディを使用して新しいバージョンのリソースを API クライアントに渡したいのですが、追加のデータを含めることはうまくいきません。

4

3 に答える 3

4

reason フレーズで非 ASCII 文字を渡すための合意された方法はないため、実験環境の外で動作する必要がある場合は、これに頼ることに細心の注意を払います。

ローカライズされたメッセージを応答本文に移動すると、より信頼性が高くなります。

于 2011-03-07T09:55:58.493 に答える
3

RFC からわかるように:

Status-Code はオートマトンによる使用を意図しており、Reason-Phrase は人間のユーザーを対象としています。

そのため、ユーザーフレンドリーでありながら、短くて要点をまとめたものとのバランスを見つけることは価値があります。私が見た多くの Web サービスには、コードを含むステータス ノード (xml または json) と、よりわかりやすいメッセージが応答データの一部として含まれています。

1 つの潜在的な問題: RESTful API の 1 つで、デバッグを支援するために理由フレーズをカスタマイズしました。Pingdom でアップタイムを監視していましたが、ステータスが RFC で提案されているものと一致した場合 (すなわち200 OK)、サービスが利用可能であると誤って受け入れていました。これが正しくないことを彼らに指摘したので、私は RFC(!) に言及されましたが、最終的に彼らはそれを誤解していたことを認めました。

于 2011-03-07T09:38:39.173 に答える
0

ベスト プラクティスは、これに ASCII 英語メッセージを使用し、ブラウザが正しいことを行っており、これらのフレーズをまったく表示していないと想定することです (以下の詳細を参照)。

HTTP/1.1 RFC 2616で定義されている HTTP 1.1 応答行の現在のステータスと、 RFC 7230および7231の更新は次のとおりです。

  • ステータス行の形式は次のとおりです。HTTP-Version Status-Code Reason-Phrase CRLF
  • Reason-Phraseは、とTEXT以外の文字です。RFC 7230 では、実際には、クライアントは reason-phrase content を無視すべきであると述べています。ブラウザーは、これらの理由フレーズをユーザーに表示するべきではありません。これらは、テキストベースのブラウザーを対象としていました。ただし、最新のブラウザが依然として理由フレーズをユーザーに表示する可能性がある状況についての明確なドキュメントは見つかりません。CRLF
  • このTEXT規則は、メッセージ パーサーによって解釈されることを意図していない記述フィールドの内容と値に対してのみ使用されます。MAYの単語には、 RFC 2047*TEXTの規則に従ってエンコードされた場合にのみ、ISO-8859-1 (RFC 2616 による) 以外の文字セットの文字が含まれます。
  • RFC 2047 では=?iso-8859-1?q?test_S=EEne_li=F0e?=、またはのような構文が指定されています=?utf-8?b?dGVzdCBTw65uZSBsacOwZSDhmqDhm4fhmrsgz4PPgM6vz4TOuQ==?=。これは他の HTTP ヘッダーのエンコード方法ですが、現在のブラウザーではサポートされていないようです (Chrome と Firefox でテスト済み)。
  • Chrome と Firefox で簡単なテストを行ったところ、Javascript コンソールと [ネットワーク] タブに表示される内容に基づいて、レスポンス フレーズに UTF-8 または ISO-8859-1 を使用することでマイレージが異なる可能性があることが示されましたが、RFC 2047 の MIME スタイル エンコーディングは決して機能しません。

これをテストするために使用した非常に単純な Python 3 サーバーを次に示します (例については、http: //127.0.0.1 :8080/UTF-8またはhttp://127.0.0.1:8080/rfc2047にアクセスしてください)。

# -*- coding: utf-8 -*-
import sys
from email.header import *
from http.server import HTTPServer, BaseHTTPRequestHandler
from socketserver import ThreadingTCPServer

class TestHTTPRequestHandler(BaseHTTPRequestHandler):
    def handle(self):
        data = str(self.request.recv(1024), 'ascii')
        print("Received request: %r" % data)
        if 'GET /' in data:
            encoding = data[data.find('GET /')+4:]
            encoding = encoding[:encoding.find(' ')].lstrip('/')
            if '?' in encoding:
                encoding = encoding[:encoding.find('?')]
        else:
            encoding = "iso-8859-1"
        if encoding == 'favicon.ico':
            self.request.sendall(b'HTTP/1.1 404 Not Found\r\n')
            return
        reason_phrase = "test Sîne"
        if encoding == "rfc2047":
            encoding = "utf-8"
            reason_phrase = Header(reason_phrase, encoding).encode()
        response = (u"HTTP/1.1 500 %s\r\nContent-Length: 10\r\nContent-Type: text/plain; charset=%s\r\nConnection: Closed\r\n\r\n\"testSîn\"" % (reason_phrase, encoding))
        self.request.sendall(response.encode(encoding))

server = ThreadingTCPServer(('127.0.0.1', 8080), TestHTTPRequestHandler)
try:
    server.serve_forever()
finally:
    server.server_close()
于 2020-05-12T12:02:59.753 に答える