WordPress HTTP API を探索する: wp_remote_get とその応答について学ぶ-PHPチュートリアル-php.cn

探索 WordPress HTTP API：了解 wp_remote_get 及其响应

このシリーズでは、wp_remote_get WordPress HTTP API 関数を検討し、その仕組み、使用方法、受け入れられるオプションのパラメーターを理解しました。

ここから詳細なリクエストを書くことができますが、それは半分にすぎず、応答もあります。

2 回目の記事では、基本的な応答がどのようなものであるか、それを評価する方法、および画面に表示する方法について説明しましたが、実際の応答については詳しく説明しませんでした。 p>

より高度なリクエストを作成し、より防御的なコードを作成したい場合は、応答として送信されるデータを理解することが重要です。最後の記事では、まさにそれを行います。

応答を見る

まず、防御的なコードを書くという意味を理解することが重要です。ソフトウェアを作成するとき、ユーザーが何か間違ったことをしたり、入力が正しく設定されなかったり、データが取得されたり、受信した場合 - 例: 応答の場合 - 間違っています。

これを行うために、ソフトウェアが完全にクラッシュしたり、ユーザーが使用中にクラッシュしたりしないように、これらのシナリオに合わせて防御的にコーディングします。代わりに、正常に失敗し、実行を継続します。

リクエストに応じて関数が何を受け取るかを正確に知ることで、どのデータを探すべきかがわかり、期待どおりにデータが返されない場合に状況を適切に処理する方法がわかります。

応答例

何が予想されるかを準備するために、サンプル応答を見てみましょう。 URL に対して GET リクエストを実行すると、単純なテキストが返されます。

一般に、応答が XML や JSON などになるような、より複雑なリクエストを作成する場合がありますが、その情報はすべて、応答配列の body インデックスに設定されます。したがって、何が起こるかを知っていれば、それに対処する方法もわかります。

そうは言っても、これはドメインへの単純なリクエストから受け取ると予想される応答であり、プレーンテキストのみを返します。

リーリー

は単なる配列 (または実際には配列の配列) にすぎません。 悪いことは何もありませんね?

各応答要素を詳しく見てみましょう。

＃＃＃タイトル＃＃＃

上記の応答からわかるように、ヘッダーは実際には追加情報を含む別の配列で構成されています。

上記の各情報を確認する前に、ヘッダーとは正確には何なのかを理解することが重要です。簡単に言うと、ヘッダーは、クライアントとサーバーの間に存在する要求/応答通信に関する情報を提供します。

送り返すことができるヘッダーにはさまざまなものがありますが (その多くはこの記事の範囲外です)、それらはすべて、リクエストに関する情報だけでなく、リクエストを行っているサーバーに関する情報を取得するのにも役立ちます。コミュニケーションをとっています。

そうは言っても、各ヘッダー要素を詳しく見てみましょう。

＃＃＃日付＃＃＃

これは非常に理解しやすい要素です。単純に、これはメッセージが送信された日時です。これには、世界標準時間であるグリニッジ標準時の曜日、日付、時刻が含まれることは明らかです。

＃＃＃サーバ＃＃＃

server 要素は、サーバーが実行するソフトウェアの種類を指します。通常は Apache が目に入ると思いますが、現在は IIS や今後登場する nginx など、他のサーバーアプリケーションも利用できます。

X-Powered-By

X-Powered-By は、通信トランザクションのサポートを提供するサーバーソフトウェアを指します。この例では PHP が表示されていますが、これは単にリクエストが Apache と PHP を実行しているサーバーに送信されることを意味します。

しかし、常にそうであるとは限りません。

たとえば、nginx と Python を実行しているサーバー、または Ruby on Rails を実行している他の種類のサーバーソフトウェアと通信することになる可能性があります。

Xサーバー

この特定の応答要素は、リクエストの送信先サーバーの IP アドレスを参照します。この特定の情報を知る必要があることはほとんどありませんが、他のすべての情報が適切であるように見えても、予期しない応答を受け取った場合は、サーバーの IP がリクエストの送信先と予想されるドメインと一致するかどうかを知ると役立つ場合があります。 . 助かりました。

＃＃＃期限切れ＃＃＃

リクエストが行われ、応答が送信されるたびに、応答にはライフサイクルがあると言えます。

より具体的には、応答は一定の時間が経過すると「古い」とみなされます。明らかに、応答が古いとみなされる時間は、応答が期限切れであるとみなされる時間です。

応答が古くないとみなされる時刻はサーバーの構成によって異なりますが、タイムスタンプは要求の日付と同じ形式になります。

キャッシュ制御

キャッシュ制御とは、Web ブラウザ (またはクライアントとサーバーの間に存在する他のキャッシュメカニズム) が最初の応答を今後の要求への応答として使用する場合と使用しない場合があるという概念を指します。

たとえば、サーバーが

no-cache

で応答した場合、要求側マシンのブラウザ、サーバー、またはその他のプロキシソフトウェアまたはキャッシュメカニズムが各応答を新しい応答として扱う必要があることを意味します。一方、

no-cache

が指定されていない場合、(少なくともキャッシュの有効期限が設定されるまでは) 最初の応答が取得できる唯一の応答になる可能性があります。

これは明らかに 2 つのインデックスで構成されています:

最初のインデックスには no-cache それが設定されているかどうかが含まれます
2 番目のインデックスには、データがキャッシュされているかどうかに関する情報が含まれています。簡単に言えば、post-check および pre-check 間隔が期限切れになった場合は、データの更新バージョンが要求されます。それ以外の場合は、キャッシュされたバージョンが要求されます。回収される。

キャッシュのこの特定の側面については、さらに詳しく記述および説明できるため、このシリーズの範囲を超えていますが、表示されているヘッダーの説明には上記の定義で十分です。

＃＃＃バラエティ＃＃＃

このヘッダー値は、要求側サーバーに同様の後続の要求の処理方法を指示するという点で Cache-Control ヘッダーに似ています。

一般に、これはキャッシュされた応答を使用できるか、それとも新しい値を取得する必要があるかをサーバーに示します。これは過度に複雑になる可能性のあるもう 1 つの要素ですが、説明をより広範な範囲に要約するために、さまざまなヘッダー要素を使用して、サーバーが期待するさまざまなコンテンツタイプをサーバーに示すこともできます。

クライアント

はそれを処理できます。したがって、上記の例では、クライアントがエンコードされた情報を処理できることをサーバーに指示します。

コンテンツの長さ

Content-length は、キャッチ付きの単純な概念です。まず、単に応答本文の長さを定義するだけです。

問題は、それが 8 ビットバイトで行われることです。これは、応答がキロバイト、メガバイト、または通常目にするいかなる形式のデータでも提供されないことを意味します。

これを行うには、返されたデータに関するより豊富な情報を収集したい場合、いくつかの変換を実行する必要がある場合があります。

＃＃＃接続する＃＃＃

接続値は、要求元のブラウザーが優先する接続タイプを指定します。上では、値が「close」として定義されていることがわかります。これは、応答が送信されると接続を閉じることができることを意味します。

ただし、他のオプションもあります。たとえば、「キープアライブ」を受信する場合がありますが、これは明らかに接続をしばらく維持することを要求します。

これは、完全に説明するには別の記事が必要なさらに別の例ですが、これにより、サーバーが優先する接続の種類についての洞察が得られ、将来のリクエストを組み立てるのに役立ちます。

コンテンツタイプ

これは実際には、

POST

リクエストと

PUSH

リクエストにのみ関係します。つまり、これはリクエストのボディタイプを定義します。これは、送信されるデータによって異なる場合があります。エンコードされた URL の場合もあれば、PHP の場合もあり、他のものである場合もあります。いずれにせよ、これにより、コンテンツで返されたデータがリクエストに基づいて予想されたものと一致することを確認できるようになります。 ＃＃＃文章＃＃＃body 要素には、実際にはサーバーから返された情報が含まれています。

前の 2 つの記事の例では、Twitter から JSON 文字列を受け取りました。上の例では、単純なテキスト文字列を受け取ります。最終的に、応答は何らかの形式のバイナリデータとして返される可能性があり、ある程度の逆シリアル化が必要になります。

いずれにせよ、ユーザーに表示する前に応答を適切にデコードする方法を理解することは、リクエスト実装者としての責任です。

＃＃＃応答＃＃＃

応答は実際には、サーバーから要求側クライアントに送り返される HTTP 応答コードを指します。 HTTP ステータスコードに詳しくない場合は、非常に良いリファレンスとして HTTPStat.us をチェックすることをお勧めします。

つまり、応答は数値コードと、要求の結果を示すテキストベースのメッセージで構成されます。

コードとメッセージ

上の例では、ステータスコード「200」と「OK」メッセージを受信したことがわかります。コードとメッセージの対応は常に相互に同期されます。

これは、「403」を受信した場合は「Forbidden」メッセージも受信する必要があり、「404」を受信した場合は「Not Found」メッセージを受信する必要があることを意味します。

個人的には、これらの特定の値は、自分が行っているリクエストに問題があるかどうかを診断する際に非常に重要であると感じています。

＃＃＃クッキー＃＃＃

最後に、Cookie 配列は、現在のクライアントと、それと通信するサーバーの間に存在する Cookie に基づいて、ネットワーク経由で送信される情報を指します。

リクエストの性質に応じて、これは空の場合と空でない場合があります。これはケースバイケースで大きく異なるため、明確なガイダンスを提供することはできません。つまり、2 つの接続間で Cookie が確立されていない場合、その接続は常に空である可能性が高く、そうでない場合、Cookie 配列を構成するデータは 2 つのサービス間に存在する Cookie のみに基づくことになります。

＃＃＃結論は＃＃＃

全体として、データの量は非常に多く、受信を要求したものとサーバーの応答に応じて、データ

は要求ごとに異なります

ただし、問題は、次のことがわかったことです。何が予想されるか、そしてそれをどのように正しく行うかあらゆる状況に対処します。

状況がさらに悪化した場合は、いつでもデバッガーを使用するか、

print_r

や

var_dump

などのデバッグステートメントを入力してサーバーが何を返すかを確認できるため、エラーを適切に処理できます。。