Web サービスとして使用する C++ API を作成しています。API の関数は、images/path_to_images を入力パラメーターとして受け取り、それらを処理して、別の一連の images/paths_to_images を出力として提供します。私は、REST インターフェイスを実装して、開発者がプロジェクトでこの API を使用できるようにすることを考えていました (作業したい言語に関係なく)。しかし、REST が適切なのは、照会または操作したいデータのコレクションがある場合に限られることは理解していますが、ここでは正確には当てはまりません。[私が持っているコレクションは、提供されたデータを操作するさまざまな機能のものです。]
では、これには RPC インターフェースを実装する方がよいでしょうか、それとも REST 自体を使用してこれを行うことができますか?
REST は一般的な操作 GET、POST、DELETE、HEAD、PUT を使用します。ご想像のとおり、これは非常にデータ指向です。ただし、データ型に制限はなく、データのサイズにも制限はありません (とにかく私は知りません)。そのため、ほぼすべてのコンテキスト (バイナリ データの送信を含む) で使用できます。REST の利点の 1 つは、Web ブラウザーが REST を理解し、ユーザーが要求を送信するための専用アプリケーションを用意する必要がないことです。
RPC はより多くの可能性を提供し、使用することもできます。たとえば、カスタム操作を定義できます。あなたがやろうとしていることを考えると、それほど多くの力が必要かどうかはわかりません。
個人的には REST を使用します。
読みたいリンクは次のとおりです: http://www.sitepen.com/blog/2008/03/25/rest-and-rpc-relationship/
lcfseth と同様に、REST も使用します。REST は確かにリソース ベースであり、あなたの場合、処理するリソースがないと考えるかもしれません。ただし、それは正確には当てはまりません。システムの画像コンバーターがリソースです。それに画像を POST すると、新しい画像が返されます。したがって、次のような URL を作成するだけです。
POST http://example.com/image-converter
それに画像を POST すると、新しい画像へのパスを含む配列が返されます。
潜在的に、次のこともできます。
GET http://example.com/image-converter
これにより、画像変換のステータスがわかります (時間のかかるプロセスであると仮定します)。
このようにする利点は、開発者が使い慣れた HTTP 動詞を再利用できることです。インターフェースはほとんど自己文書化されています (ただし、もちろん、POST 呼び出しによって受け入れられ、返される形式を文書化する必要があります)。RPC では、新しい動詞を定義して文書化する必要があります。
RPC に比べて REST の (json 形式のインターフェース) は軽量で、API ユーザーにとって使いやすいです。RPC(soap/xml) は複雑で重いようです。
あなたが望むのは HTTP+JSON ベースの API であり、REST の作成者http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-drivenが主張する REST API ではないと思います