2

私は、ユーザーが新しいリソースを送信できるようにする既存のウィザードをサポートするための安らかなサービスの設計に取り組んでいます (それを呼び出すことができますcustomer)。

このウィザードは、ユーザーが送信するページごとに検証を行いますが、ユーザーが送信しているページに対してのみ検証を行います。ユーザーが最終処理のために顧客を送信することを選択した場合にのみ、オブジェクト全体に対して完全な検証パスが実行されます。

ウィザードを簡素化し、さらにフィールドを追加するときにメンテナンス リリースで UI をシャッフルできるようにするために、ウィザードの構造をリソースに体系化していません。顧客は、ウィザードがデータを提示する方法で「ロールアップ」しません。

リソースの名前付きサブドキュメントが必ずしもそのリソースの完全なドキュメントに階層的に表示されない (または少なくとも同じ方法ではない) ように RESTful サービスを設計するのは奇妙ですか?

私のウィザードページが次のとおりだったとします。

  • 連絡先
  • 食べ物の好み
  • 恐れのリスト

次に、顧客オブジェクトの例を示します。

// Note that the wizard page groupings don't show up explicitly
{
    customer: {
        firstName: "Pilsner",
        lastName: "Dopplebock",
        emailAddress: "nextguest@hotelcalifornia.com",
        addressLine1: "123 Fleece Place",
        addressLine2: ""
        town: "Ibinjad",
        region: "North Dakota",
        postalCode: "12123",
        homePhoneNumber: "2123234124",
        faxPhoneNumber: null,
        meatPreference: "well-done",
        allergies: "shellfish",
        fears: [
            "banshees",
            "baths",
            "sleeveless shirts"
        ]
    }
}

リソースのベース URL を次のようにします。

http://www.somewhere.com/customers
http://www.somewhere.com/customers/{id}

以下の安らかな URL/メソッドを作成するのは奇妙でしょうか、それとも間違っていますcustomerか?

http://www.somewhere.com/customers/contactinformation (POST)
http://www.somewhere.com/customers/{id}/contactinformation (POST, or PUT for update? maybe GET)
http://www.somewhere.com/customers/{id}/foodpreference (POST, or PUT for update?, maybe GET)
http://www.somewhere.com/customers/{id}/fears (POST to add a single item?, maybe PUT for a batch?, maybe GET)

リソース全体を一度に取得できない場合は、別のウィザード URL を使用することを検討しましたが、私の意見では、これは適切にリソース指向ではないようです。

http://www.somewhere.com/customerwizard/submitcontactinformation (POST)
http://www.somewhere.com/customerwizard/{customer-id}/submitcontactinformation
http://www.somewhere.com/customerwizard/{customer-id}/submitfoodpreference
http://www.somewhere.com/customerwizard/{customer-id}/fears

(関連しているかもしれませんが、おそらく 2 番目の質問):countメイン コレクションに必ずしも表示されないコレクション スタイルのリソースのサブプロパティがあるのは奇妙ですか? ページ分割されたビューをサポートするためにこれを行いたい...

http://www.somewhere.com/customers/count (GET)
4

3 に答える 3

0

この質問は引用されたものと重複しているとは思いません。現存するリソースの部分的な更新を実行するように要求するのではなく、サーバーに「部分的な」リソースを検証するように要求します（これは、後でユーザーに通常提示するリソースではなく、それ自体がリソース全体であると私は主張します）。

このような場合、RESTは必ずしも正しいオプションではありません。RESTは、分散している可能性のあるオーディエンスが複数回アクセスする静的または半静的リソースの読み取りアクセスを最適化するように設計されています。助けるために、あなたはこれらの質問に答えることができます：

  1. 最初の要求と応答の通信が完了した後で、検証の結果を取得したいと思ったことはありませんか？
  2. 同じデータを（異なるユーザーまたは同じユーザーから）2回送信することはありますか？
  3. もしそうなら、応答は常に同じでしょうか？つまり、検証アルゴリズムは決定論的ですか？
  4. これらのデータをすべて暗号化せずに、他の人にわかりやすく送信しても大丈夫ですか？

これらすべてに「はい」と答えた場合は、RESTが適しています。3つすべてに「いいえ」と答えた場合、RESTは適切ではありません。混合された答えは決定を幾分混乱させます。

私があなたの立場にあり、それ以上のデータがなければ、データキャッシングとセキュリティ要件が何であるかがわかるまで、HTTPSを介したRPCインターフェイスとして最初に実装し、システムのどの部分が必要かを知ることができました。キャッシュの恩恵を受ける（エンドユーザーのマシン上でのみ、またはパブリックリソースが暗号化されずに送信され、仲介者によってキャッシュ可能になる場合。

HTTPベースのAPIの分類と呼ばれるすばらしいリソースがあり、RESTが実際にAPI設計でたどりたいパスであるかどうかを判断するのに役立つ可能性があります。代替設計を選択することには「間違った」ことは何もないことを覚えておいてください。それはトレードオフです。それぞれの長所と短所に基づいて、十分な情報に基づいて決定を下します。

于 2013-01-23T11:26:46.243 に答える
0

URLのいいね/customers/{id}/contactinformationなどはおかしくないです。自問したい 1 つの質問は、書き込み時に Customer エンティティを個別のフラグメントに分割することが理にかなっているという事実が、読み取り時に個別に提供された方が良いという意味ではないかどうかということです。これにより、HTTP キャッシングがより適切になることは間違いありません。たとえば、エンティティ フラグメントに PUT してから親を GET すると、その後のフラグメントへの PUT はフラグメントを無効にするだけで、親は古いデータを提供する可能性があります。より小さな親エンティティ (各エンティティ フラグメントへのリンクを持つ) を GET してから各フラグメントを GET する方が簡単です。

于 2013-01-23T15:40:18.447 に答える