... 個人的にはあんまり実装したくないんだけどゲームはランキング表示や諸々の都合のためにHTTPアクセスが必要で、かつ、メッセージングのためにWebSocketが欲しいとも言われている。

まぁ暫くはNode.js上の実装で我慢してもらうとして、流石にNode.jsをdependencyとして持つのはいかがなものかということでC APIを検討したい。

サーバーは ↓ でやったけど、今回はクライアント編。

WebSocketの必要性

元々の fetch にはWebSocketの機能性は無いので、そこにWebSocketを混ぜるかどうかは非常に悩みどころと言える。。どうせ放っておけばWebTransportが来るしなぁ。。

cpp-httplib

cpp-httplib にはクライアント機能もある。

Beastにもクライアント機能がある。。が、率直に言ってあんまり真面目な実装に見えない。

Pocoにもクライアント機能がある。。が、これ自体がself-containedなライブラリを目指していて、でかい。

libcurlはどこにでもあるHTTPクライアントライブラリで、いわゆるlinux環境であれはdependして問題ないだろう。

ただし、curlにはグローバルコンテキストが存在するので、C-Fetchを使うプログラムの別のところでcurlを使う場合に注意が必要になる。多くの場合使用されるのは easy インターフェースで、これはグローバルコンテキストの存在を隠蔽するので、 easy だけ使うのが良いのかもしれない。

MSのlibHttpClientはプラットフォームHTTPクライアントのwrapperで、Android上であれば okhttp3経由で実装したHTTPクライアントを呼出す。 ...ってokhttp3はSquare製のライブラリであってプラットフォームのHTTPじゃなくない。。？

プラットフォームのHTTPを使うのは割と重要で、システムのproxyを尊重するという点の他に、iOSではBSD socketはカーネル実装だが URLSession はユーザランド実装のネットワークスタックになるので安全性の面でも違いが出てくることになる。

ただし、HttpURLConnectionを直接利用することはあまりなく、実際は OkHttpなどを利用してAPIにアクセスすることが多いでしょう。

一般に、Androidで HTTPURLConnection を使わない理由はAPIがJava由来で古いのと、redirect等のコーナーケース処理が無い点に見える。でもそれくらい我慢してくれても良くない。。？