1

REST Api を開発するとき、私がオブジェクト レベルのメタデータ、CreatedBy、CreatedOn、ModifiedBy、ModifiedOn などと呼んでいるものを処理する最良の方法は何ですか?

典型的なクラスは次のとおりです。

public class Person {
    public Guid Id {get; set;}
    public string FirstName {get; set;}
    public string LastName {get; set;}
    public DateTime CreatedOn {get; set}
    public Guid CreatedBy {get; set;}
}

私は理想的な世界では、REST http メソッドは次のようにコントローラ メソッドに直接マッピングされると考えていました。

public void Post (Person person) {
    ...perform the logic to add a person.
}

したがって、API の消費者は理論的に次のように投稿できます。

{
     "Id": "...guid...",
     "FirstName": "Joe",
     "LastName" : "Bloggs",
     "CreatedOn" : "01/01/12",
     "CreatedBy" : "...guid..."
}

ただし、消費者設定の Id、CreatedOn、および CreatedBy は適切ではありません。これを行うのは消費者の責任ではないと思います。したがって、これにより、私のPost方法で次のことを行うことができます。

public void Post (Person person) {
     person.Id = Guid.NewGuid();
     person.CreatedOn = DateTime.Now;
     person.CreatedBy = ...get user credentials from request...
}

したがって、消費者は自由に投稿できます。

{
     "FirstName": "Joe",
     "LastName" : "Bloggs"
}

Put メソッドを使用して更新を行うにはどうすればよいでしょうか。これにより、同じ問題が残ります。消費者がこのメタデータを通過することを望まない (または信頼しない) 場合は、Putメソッドでこれを行う必要があります。

public void Put (Person person) {
     Person existingPerson = myRepository.GetEmployee(person.Id);

     existingPerson.FirstName = person.FirstName;
     existingPerson.LastName = person.LastName;

     myRepository.Save(existingEmployee);         
}

Post (Person personコンシューマーの json/xml をモデル オブジェクトにデシリアライズし、 orを通過することに本当の意味があるのではないかと考え始めてPut (Person person)います。すべてをディクショナリに逆シリアル化しないのはなぜですか (ただし、実際には json に対してのみ実行可能です)。

REST について何か基本的なことが欠けていますか? Id と 1 つのプロパティをモデル オブジェクトに逆シリアル化し、完全なオブジェクトを取得して更新するのは正常ですか? コンシューマーに毎回すべてを通過させてから検証する必要がありますか?

コンシューマーが json または xml のチャンクを通過し、それがコントローラーに到達するまでにオブジェクトを処理しているという考えが気に入っています。このすべてのプロパティを無視し、更新のために既存のレコードをプリフェッチするなど、少し面倒に思えます.RESTを根本的に誤解していない限り?

4

1 に答える 1

1

あなたが検討している設計オプションは、REST に固有のものではなく、サービス設計全般に当てはまると思います。私がこれを読んだ方法では、基本的な質問は次のように思われます-これらのフィールドにデータを入力するビジネスロジック、呼び出し元、またはサービスの責任者は誰ですか?

私の 2 セントでは、2 つの理由から、それはサーバーの責任であると考えています。何よりもまず、セキュリティ。クライアント側のスクリプトは本質的に安全ではないため、信頼するべきではありません。たとえば、やる気のある個人は簡単に監査証跡を偽造し、別のユーザーがそのアクションを実行したかのように見せかけることができます。第 2 に、audit/id フィールドの人口は、呼び出されるメソッドの実際のビジネス目的を横断するロジックとして認識されます。個人を作成するために、クライアントは ID の表現方法に関する実装の詳細を認識する必要はありません。

辞書とモデルの使用に関しては、個人的な好みだと思います。どちらのアプローチも、クライアントにフィールドの完全なセットを渡すことを強制しません。どちらも、クライアントが操作のためにプライマリ フィールド セットのみを渡す設計をサポートします。モデルまたはディクショナリへの実体化には、単に監査/ID フィールドがありません。同様に、どちらのアプローチでも、サーバー側で読み取り専用フィールドを検証する必要がなくなります。クライアントで変更されていないという保証はないからです。

于 2012-08-16T17:18:16.790 に答える