8

私たちのシステム全体はRESTを中心に設計されており、URLで動詞を使用せずに、意図的にRPCであることが非常に明確なプロセスをRESTfulリソースにマッピングする方法を検討しています。コンテンツリストが他の場所で変更された場合、リモートプロシージャコールを使用して検索インデックスを再構築します。

私たちが考えているのはこれです：

POST / index_updates

<indexUpdate><contentId>123</contentId></indexUpdate>

それ自体は何も問題はありませんが、作成されたこのリソースは、新しく作成されたリソースのURLを返しません。たとえば/ index_updates / 1234は、GETでアクセスできます。

使用しているインデックスエンジンにはログメカニズムがあるため、理論的には、GETがリソースを取得できるようにindex_updateリソースにURLを返すことができますが、正直なところ、これはリソースに関心がありません。変装したRPCにすぎません。

だから私の質問は、RESTfulnessが構造で表現されているのか意図で表現されているのかということです。私が概説したものの構造は落ち着いていると感じますが、意図はそうではありません。

誰かコメントやアドバイスはありますか？

ありがとう、

クリス

4

3 に答える 3

5

仕事に適したツールを使用してください。この場合、適切なツールは純粋なリモートプロシージャコールであるように思われ、RESTのふりをする理由はありません。

于 2008-12-22T09:43:33.263 に答える
4

POST /index_updates 呼び出しから新しいリソース識別子を返す理由の 1 つは、操作の状態を監視するためです。

POST /index_updates
<contentId>123</contentId>

201 Created
Location: /index_updates/a9283b734e

GET /index_jobs/a9283b734e

 <index_update><percent_complete>89</percent_complete></index_update>
于 2009-04-09T15:43:39.827 に答える
-2

これは明らかに主観的なフィールドですが、GET PUT POST DELETE は何でも説明できるほど豊富な語彙です。そして、私が英語を話さないアジアの国に行くとき、私が指さすだけで、私はその言語を話さないので、彼らは私が何を意味するかを知っています.

RPC を REST に偽装することは悪い考えではありません。個人的には、SOAP はバッシングされ、嫌われていると思いますが、実際には多くの強みがあります (HTTP 圧縮、HTTP/SSL、Cookie など、さらに多くの強みがあります)...そして、アプリはクライアントが呼び出すメソッドを実際に公開しています。なぜそれを REST に変換したいのでしょうか? 納得したことはありません。SOAP を使用すると、私たちが知っていて愛用しているプログラミング インターフェイスの言語を使用できます。

しかし、あなたの質問に答えるために、RPC を REST に偽装するのは悪い考えですか? いいえ。RPC を REST として偽装し、4 つの基本操作に変換することが問題です。それをかっこいいと思うかどうかは別の話です。

于 2008-12-22T19:25:05.053 に答える