RESTのパブリックAPIの代替としての節約？
作業中の新しいサイトのAPIの作成を開始しました。
私はもともとそれを通常のREST APIにしたかったのですが、複数のクライアントライブラリを1つのバッチでコンパイルする機能でどれほどクールな節約になるかを考え続けています。
ThriftはパブリックAPI、ソケット、その他すべての実行可能なオプションですか、それともRESTを使用する必要がありますか？
そして、REST複数のクライアントライブラリを作成するための最良のアプローチは何でしょうか、それとも私はただ降りて汚くして実際にそれらを書く必要がありますか？
それ以外の場合、Thriftの場合、ライブラリをコンパイルしてダウンロードリンクを提供するか、開発者に.thriftファイルを提供して独自のライブラリを生成しますか？
注：まだ小さなサイトなので、API専用のThrift仕様ファイルを作成します。
まず、RESTとThriftはリンゴからオレンジまでです。前者は一般的なスタイルで、後者は特定のバイナリRPCシステムです。
しかし、パブリックインターフェイスの場合、REST標準のテキスト形式（通常はJSONまたはXML）を使用する方が理にかなっていると思います。どの言語やプラットフォームからでも簡単にアクセスできるため、Thriftクライアントもありますが多くのプラットフォームでは、さらに手間がかかります。また、クライアントに特定のアクセススタイルを強制し、特定のThriftクライアントライブラリを使用する必要があります。
それで、質問はむしろあなたが正確に何を得ようとしているのかということです。そこで「かっこいい」とは正確には何だと思いますか？新しいテクノロジーで遊びたいだけなら、それは何も悪いことではありませんが、最初にそれで遊んでから、それが理にかなっているかどうかを確認する必要があります。
APIがRESTで表現でき、許容できるパフォーマンスで表現できるほど単純な場合は、通常、RESTのクライアントコードを作成する際の障壁が低いため、RESTを使用する方がよいでしょう。 _ベースのAPI。
一方、RESTに複雑さやパフォーマンスの問題がある場合は、節約など、より適切な方法を選択してください。
RESTの大きな利点の1つは、クライアントライブラリを作成する必要がないことです。開発者にエンドポイントのリストを指定するだけで、そこからそれを理解できるはずです。 。いくつかの大きく不適切に設計されたRESTサービスは、醜さを隠すためのクライアントライブラリを提供しますが、APIが単純で適切に設計されている場合は、必要ありません。
自分で別のライブラリを開発する場合は、同じボートに乗ることになります。 RESTは、ライブラリがなくても（または独自に実装していれば）使いやすいと思います）。一方、Thriftの好きなところがバイナリである場合、jsonは次のことができます。同様の方法で使用することもできます。詳細については、こちらを確認してください http://bsonspec.org/