私はすべて REST Web サービスに賛成であり、私の会社には SOAP よりも REST を優先するポリシーがあります。
ただし、リソース パラダイムに適合しない Web サービスを公開する必要があります。これは基本的に計算であり、多数のパラメーター (約 20 フィールド) を送信して数値を取得する必要があります。
HTTP POST を使用して、リクエスト本文で JSON オブジェクトを送信することを考えました。ここでの問題は、私の Web サービスが SOAP-WS と REST をサポートしており、このアプローチがこれらのカテゴリのいずれにも該当しないことです。
私の質問は、ここでのオプションは何ですか? これを RESTful WS に適合させることはできますか?
おっしゃるとおり、REST は、リソースに対してCRUD操作を公開する場合に意味があります。通常、これらのリソースは、何らかのデータベースまたはストレージ メカニズムで永続化されます。
あなたの場合、ストレージやリソースはないと思います（一連の数値を提供して結果を返しますが、何も保存されません、それは本当ですか？）。そのため、そのような WS を「RESTful」と呼ぶことはできません。
そうは言っても、REST は「哲学」に近いものです。お好きなパーツを取ってご使用いただけます。POST を実装し、入力で JSON 構造を取り込み、結果で JSON を返すというあなたのアイデアは良さそうです。また、「 application/x-www-form-urlencoded 」コンテンツを POST することもできます (通常のフォームが送信され、意味がある場合は結果が「text/plain」として返されます。
アイデアは、理解しやすく操作しやすい WS を構築することです。SOAP-WS とは正反対です。;)
調査の結果、このディスカッションに本当に関連する記事が見つかりました：http: //info.apigee.com/Portals/62317/docs/web%20api.pdf
それが RESTful にならない理由がわかりません。特定の計算の実行を、独自の ID ( /calculation/ID123) を持つリソースと見なします。次に、POST を実行し/calculationて新しいパラメーターを作成し、GET/PUT を実行/calculation/ID123/paramAして特定のパラメーターを操作し、GET を実行/calculation/ID123/resultして計算の結果を取得できます (または、計算結果が何らかの理由で利用できないという記述)。 . もちろん、GET を/calculation実行すると、表示できる保存済みの計算のリストが取得されます。GET を実行すると/calculation/ID123、上記のサブリソースの説明 (および提供したいその他の情報) が取得されます。特定の計算は DELETE です。
多くのサブリソースと非常に一時的なリソースを使用しても問題はありません。覚えておくべき重要なことは、クライアントが URL を作成してはならないということです。(この状況でコンテンツ ネゴシエーションがそれほど有用かどうかはわかりません。それは、私が推測する特定の計算に大きく依存します。)