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