ウェブ以外のアプリケーション用のREST型API、それは良い考えですか？

Question

C++とJavaの両方で、ゲーム開発者、アニメーションソフトウェア開発者、Avatar開発者などがライブラリ/ DLLとして使用して製品を強化するためのミドルウェアSDKを開発しています。

特定の関数の特定の呼び出しを使用して標準的なAPIを作成しましたが、REST型API（GET、PUT、POST、DELETE）またはCRUD型（CREATE、READ、UPDATE、DELETE）インターフェイスを使用してAPIを単純化することを検討しています。

これが唯一の4つの可能なAPI呼び出しているが、これらは柔軟なパラメータを取ることができ、クライアント・サーバ型のREST APIと同様に働くだろう。

これは、新しいコールでAPIが安定することの利点が追加されていないと、古いコールが削除されていない持っているようです。したがって、このAPIのコンシューマは、ミドルウェアの更新に合わせてコードを再コンパイルして変更する必要がないことを心配する必要はありません。

オーバーヘッドは、ルートAPIコールにミドルウェアコントローラにリダイレクトの追加の層が存在することで、開発者は、パラメータが（もちろん供給）各REST呼び出しのために利用可能であるかを知る必要があります。

私はこれまでのところ、私の質問はこれですので、ウェブ型のクライアントサーバーアプリケーションの外部で使用されるこのシステムを見ていない：これは実現可能なアイデアですか？

例えば、ゲーム開発者が使用することが容易に見つけるならば、私はその効率の面で考えると同様にしています。

Answer 1

はい、これは実現可能な考えです。しかし、そのメリットがコストを正当化するかどうかはわかりません。 RESTは、要求と応答を中心としたネットワーク化されたアプリケーションシナリオに最も適しています。均一なインタフェースには明確な学習曲線の利点がありますが、これらの利点は、合理的に抽象的な手順を提供するほとんどすべての適切に設計されたAPIに存在する可能性があります。

また、ゲーム開発者が使いやすいRESTful APIを見つけられるかどうかについても懸念を表明しています。私は疑わしいだろう。私は多くのRESTfulなWebサービスを実装しており、多くの開発者がそれらの構築と使用のスピードアップに役立ちました。また、RESTを理解するために必要な概念的な飛躍は、数年にわたって手続き型APIに浸透してきた人にとって、私は、特にゲーム開発者は手続き型APIと非常に強く結びついていると思います。その利点が何であれ、非常に難しいかもしれないという異なるパラダイムを採用しようとすると、

Answer 2

は、RESTはHTTPに特異的ではなく、わずか4つのHTTP動詞に依存しないことに注意してください。使用している動詞と使用できる動詞は、使用しているプロトコルによって異なります。