4

ASP.NET Web API を使用して、SOAP ベースの RPC スタイルの「Web サービス」を JSON ベースの REST Web サービスに変換しています。AddXYZ / UpdateXYZ / RemoveXYZ などのメソッドは、POST/PUT/DELETE の HTTP 動詞にきれいにマップされます。「ExecuteXYZ」や「AssignXYZ」スタイルのメソッドなどの典型的な RPC スタイルの操作を対応する REST にマッピングするためのベスト プラクティス/ガイダンスはありますか? 私の見解では、そのような操作は、「ExecuteXYZRequest」や「AssignXYZRequest」などの対応する URL アドレス指定可能なリソースにマップされると考えています。

http://myhost/myservice/ExecuteXYZRequest
http://myhost/myservice/AssignXYZRequest

「ExecuteXYZ」を実行する要求は、POST 操作に変換されます。

送信されたリクエストを取得すると、GET に変換されます (通常、送信されたリクエストのステータスを取得するために使用されます)。

http://myhost/myservice/ExecuteXYZRequest/1   <--- 1 is the ID of the request

リクエストをキャンセルすると (キャンセル可能であると仮定して)、DELETE に変換されます。

POST は実際には何にもマップされません。

上記は合理的な REST 実装のように聞こえますか、それともここでの私の考えは完全に間違っていますか? 思考/ガイダンスは大歓迎です。

更新 ここに私がモデル化しようとしている特定の例があります: Contact エンティティと Event エンティティの間の多対多の関係。イベントへの連絡先のメンバーシップをRESTリソースとしてモデル化して、連絡先をイベントに追加/削除できるようにする最良の方法は何でしょうか。RPC ランドでは、これは、両方のエンティティの ID を取得し、これら 2 つの関係を設定する「AssignContactToEvent」などのメソッドになります。これを REST でリソースとして自然にモデル化するにはどうすればよいでしょうか。リンクと「rel」の概念があることを思い出しますが、Web APIを使用してこのようなものをモデル化する方法を示す具体的な実用的な例を見つけることができません

4

3 に答える 3

7

問題は、投稿に示されているように、RPC メソッドを REST リソースにマップすることが理にかなっているのかどうかです。

手短に; いいえ、あなたが説明した方法でメソッドをリソースにマップするのは意味がありません:)

「REST を行う」ことに成功するには、少し考え方を変えて、RPC と CRUD 操作の考えをすべて捨てなければなりません。RESTful であることを受け入れると、これらはかなり制限されます。

REST における情報の重要な抽象化はリソースです。名前を付けることができるすべての情報はリソースである可能性があります: ドキュメントまたは画像、一時的なサービス (「ロサンゼルスの今日の天気」など)、他のリソースのコレクション、非仮想オブジェクト (人物など) など。 . 言い換えれば、著者のハイパーテキスト参照の対象となる可能性のある概念は、リソースの定義に適合する必要があります。リソースは、一連のエンティティへの概念的なマッピングであり、特定の時点でのマッピングに対応するエンティティではありません。 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

メソッドまたはアクション/動詞はリソースではないため、URI には場所がありません。もちろん、人々が独自のメソッドを作成できるアプリケーションを構築している場合を除きますが、これはかなり珍しいことです!

連絡先とイベントの関係の具体的な例を挙げると、「AssignContactToEvent」は Web-API レイヤーの下で発生するアクションであり、RESTful にモデル化できないことを理解することが重要です。これが次の例の過程で明らかになることを願っています:)

まず、すべての連絡先のリストとすべてのイベントのリストをモデル化するための優れたリソースが必要です。

/contacts

/events

これらのリソースは、ID トークンによって識別される個々の連絡先またはイベントをモデル化します。

/contacts/{contact_id}

/events/{event_id}

アプリケーションのユーザーは、特定のイベントに誰が関与しているかを知りたいので、イベントの参加者のリストをモデル化するリソースが必要です。

/events/{event_id}/participants

連絡先をイベントに追加する場合、最小限の連絡先表現 (連絡先 ID のみを含む) をイベントの参加者リストに POST することができます。

POST /events/{event_id}/participants/ HTTP/1.1
Content-Type: application/json

{'id': {contact_id}}

イベントから連絡先を削除するには:

DELETE /events/{event_id}/participants/{contact_id} HTTP/1.1

アプリケーション ユーザーは、連絡先が参加しているイベントを一目で確認したいので、これをモデル化するための別のリソースが必要です。

/contacts/{contact_id}/events

同様に、連絡先のイベントのリストを取得し、POST を使用してイベントを割り当てることができるようになりました。

POST /contacts/{contact_id}/events/ HTTP/1.1
Content-Type: application/json

{'id': {event_id}}

取り入れるべき重要な点は、何か新しいものをモデル化する必要があるときはいつでも、リソースを作成するということです。データ オブジェクトのプロパティと関係を格納する方法の詳細は、Web API の背後で抽象化されます。実際、データ ストレージ テクノロジは将来、たとえばリレーショナルからオブジェクト ストアに変わる可能性があります。また、プログラミング言語やフレームワークを変更することもありますが、いずれの場合も URI (および Web-API) は同じままです。REST と HTTP は、内部で実行されるテクノロジーをはるかに超えて耐えるように設計されています。

新しいリソースを作成する最後の例として、主催者の役割を持つ連絡先のリストをモデル化するリソースを考えてみましょう。

/events/{event_id}/organisers

または、連絡先が組織しているイベントのリストをモデル化したもの:

/contacts/{contact_id}/events-organised

認証システムを使用している場合は、参加しているイベントを確認したい場合があります。

/my-account/events

これが Web-API の目的を明確にし、RESTful 原則に従うのに役立つことを願っています。

于 2013-01-30T13:19:11.033 に答える
2

私がこれまでに見た2つのアプローチがあります。

1つは、アクションが非常に少ない場合にアクションを動詞にマップして、衝突が発生しないようにすることです。したがって、アクションが安全でもべき等でもPOSTない場合、そうでない場合は安全ではないがべき等である場合PUT：

POST http://myhost/myservice/XYZ

もう1つは、アクションを論理リソースとして定義することです。

POST http://myhost/myservice/XYZ/Assignment

後でより豊かになり、私はそれを好みます。

于 2013-01-30T10:06:49.387 に答える
1

いくつかの重要なポイント

  • RPC エンドポイント -> REST エントリ ポイント

  • RPC 読み取りメソッド -> リソースに対する REST GET

  • RPC 作成メソッド -> REST POST 操作

  • PRC 削除方法 -> REST DELETE 操作

  • RPC SOAP メッセージ -> REST ペイロード

さらに、キャッシュヘッダー、@Consumes、@Produces などの Content-Type ヘッダーについて考えてください。

于 2013-01-30T05:05:36.187 に答える