PBC API ではエラーが起きると、RpbErrorRespが返るがRIAKC_ERR_GENERALが常に設定されており意味がないのでREST APIと同等の値が設定されているべきです。
例えば、get operation において、notfound が返るのは多くの場合クライアント側にとって特に問題ないので、コストの高い例外処理がトリガーされない事が望ましい。
一方で、modifiedが返る場合、データのリペアをトリガするべきか、単に再度getするべきかはアプリケーションの設計の問題である。
errmsgフィールドの様にHumanReadableなフィールドはあくまでも人間にとって分かり易い事が大切であり、その内容は長い開発期間の中で微調整されるべきであり、不安定でも仕方のないものである。
きめ細かい例外処理を実現する場合、errcode フィールドを読み取って処理するべきなので、現状のPBC API実装は望ましくない。
速度を何にも増して重視するユーザは全ての処理をPBC APIでやりたいと考えるだろう。
しかし、幾つかのAPI差分が存在する事によって全てをPBC APIで賄う事が出来ない。
PBC API ではBacket Propertiesに対するアクセスが著しく制限されており、これはつまり事実上Backetの管理はREST APIでしか行い得ないという事であり、これは望ましくない。
ある種のアプリケーションではエンドユーザ単位にBacketを作る、つまり大量のBacketを作っては捨てる事でアプリケーションの作りがシンプルで強力になるケースがある。
Link Walking は非常に便利な機能であるのにPBC APIから使えないのは非常に残念な事だ。
RpbGetServerInfoRespは貧弱すぎて全く使い物にならない。
/statsの中にはクライアントがRiakと自立協調動作する為に必要な多くの情報を含んでいる。
クライアントが高速に動作する事を望むPBC APIのユーザこそがこれらの情報を望んでいる筈だ。
すいませんラスト一箇所 typo してました。
s/instabliy/instability/