REST Api處理元數據，CreatedOn等

Question

在開發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);         
}

我開始想知道是否有真正的意義將消費者json / xml反序列化為模型對象並通過Post (Person person或Put (Person person)傳遞，因為我從中得到了最大的好處。為什么不這樣做呢？只是將所有內容反序列化為Dictionary（盡管只有json才真正可行）？

我是否缺少有關REST的基本知識？ 將Id和1屬性反序列化為模型對象，然后檢索完整的對象並對其進行更新，是否正常？ 我是否應該強迫我的消費者每次都經過所有內容然后進行驗證？

我喜歡這樣的想法，即消費者通過json或xml塊傳遞，直到到達我的控制器時，我才在處理對象。 所有這些忽略屬性並預取現有記錄以進行更新等的操作似乎有點混亂。除非我從根本上對REST有誤解？

Answer 1

我認為，您考慮使用的設計選項並非特定於REST，而是通常適用於服務設計。 在我閱讀本文的方式中，基本問題似乎是-誰負責填充那些字段，調用方或服務的業務邏輯？

對於我的兩分錢，我認為這是服務器的責任，原因有兩個。 首先-安全。 客戶端腳本本質上是不安全的，因此不應被信任。 例如，一個有上進心的人可以輕松地偽造您的審核記錄，並使其看起來好像是另一個用戶執行了該操作。 其次，我將audit / id字段的填充視為一種邏輯，它可以橫切調用方法的實際業務目的。 為了創建一個人，客戶不必知道ID表示的實現細節。

至於使用字典還是模型，我認為這是個人喜好。 兩種方法都不會強制客戶端傳遞完整的字段集。 兩者都支持一種設計，在這種設計中，客戶端僅傳遞用於操作的主要字段集。 物化到模型或字典中只會丟失您的audit / id字段。 同樣，這兩種方法都不需要在服務器端驗證只讀字段，因為不能保證不會在客戶端上更改它們。