PHP では HTTP リクエストを送る方法は数あります。わかりやすくするために、本文ではこれらの手法をまとめて ‘transports’ と書きます。HTTP API の目的は、それぞれの transports にシンプルでスタンダードな API を用いることで、出来る限り多くをサポートすることにあります。
問題であるのは、ウェブホスティングサーバーは異なった transport をサポートしていたり、そもそもサポートしていないということもあることです。そこでその問題を出来る限り多く解決する策として、transport が1つ2つ無効化されているサーバーであっても、恐らくサポートされているであろうウェブを通しての transports を提供することにあります。
他の問題として、プラグイン向け API がなかったこと、そして WordPress コアとスタンダード化されたものもなかったことです。そのため、 WordPress には色々な異なった実装がなされ、多くはプラグインとして提供されていました。プラグインの場合はもっとひどい状況で、作者が自ら実装を作りこみ、その後のサポートまで全て行う必要がありました。HTTP API を用いるための回避策が数多く必要とされていたため、サポートをすることが非常に難しい状況でした。プラグインについては多くの作者が1つか2つの transports しかサポートしていないものが数多くあり、少しでも多くの transports をサポートするためには再実装する必要がありました。
HTTP API は全てを極力シンプルに処理する事が出来る1つの API を標準化させる目的がありました。実際のオブジェクト指向で実装されていますが、API の使用法をまとめるユーティリティ機能があります。
HTTP API は WordPress 2.7 で導入され、WordPress 2.8 で拡張されました。後方互換性が必要となる場面があるため、可能であれば function_exists() の関数コールをラップし、代替手段を用意する必要があります。
WordPress 2.7 ではヘッダー、body、レスポンスの基本部分がサポート開始されました。続く WordPress 2.8 では、圧縮、クッキー、プロキシのサポートが追加されました。これら機能のいくつかはパッシブな、つまり機能を使うためにオプションを設定するなどといった必要がないものです。新しいバージョンでオプション使う場合、エラーを吐くことはありませんが、正しく動作しない可能性があります。
ほとんどの機能はオプションまたはフィルターを使うことでセットできる一方、プロキシの実装は定数に依存します。そのため、手動で wp-config.php に設定する必要があります。もちろん、WordPress の管理画面から設定するためのプラグインがあるかもしれません。
参考：