3

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

特定の関数の特定の呼び出しを使用して典型的な API を作成したので、REST タイプの API (GET、PUT、POST、DELETE) または CRUD タイプ (CREATE、READ、UPDATE、DELETE) インターフェースを使用して API を簡素化することを検討しています。

これは、可能な API 呼び出しが 4 つしかないクライアント サーバー タイプの REST API と同様に機能しますが、柔軟なパラメーターを使用できます。

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

オーバーヘッドは、API 呼び出しをルーティングするためにミドルウェア コントローラーに追加のリダイレクト レイヤーがあり、開発者は各 REST 呼び出しで使用できるパラメーターを知る必要があることです (もちろん提供されます)。

このシステムが Web タイプのクライアント サーバー アプリケーション以外で使用されているのを見たことがないので、私の質問は次のとおりです。これは実行可能なアイデアですか?

効率性や、例えばゲーム開発者が使いやすいかなどを考えています。

4

2 に答える 2

3

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

また、ゲーム開発者が RESTful API を使いやすいと感じるかどうかについても懸念を表明しました。私は疑わしいでしょう。私は多くの RESTful Web サービスを実装し、多くの開発者がそれらの構築と使用の両方を迅速に行えるように支援してきました。REST を理解するために必要な概念の飛躍は、手続き型 API に何年も浸かってきた人にとってはかなりのものになる可能性があります。特にゲーム開発者は手続き型 API に非常に強く結びついており、別のパラダイムを採用しようとすると、その利点が何であれ、非常に困難になる可能性があると思います。

于 2008-09-15T13:09:09.773 に答える
1

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

于 2009-07-23T14:27:19.480 に答える