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);         
}

我开始怀疑将消费者 json/xml 反序列化为模型对象并通过Post (Person personor是否有任何真正意义，Put (Person person)因为我从中获得了最微不足道的好处。为什么不将所有内容反序列化为字典（尽管仅对 json 真正可行）？

我错过了一些关于 REST 的基本知识吗？可能将 Id 和 1 属性反序列化为模型对象，然后检索完整对象并更新它是否正常？我是否应该强迫我的消费者每次都通过所有内容然后验证它？

我喜欢消费者通过一大块 json 或 xml 并且当它到达我的控制器时我只是在处理一个对象的想法。所有这些忽略属性和预取现有记录以进行更新等似乎有点混乱。除非我从根本上误解了 REST？

4

1 回答 1

1

在我看来，您正在考虑的设计选项并非特定于 REST，而是通常适用于服务设计。按照我的阅读方式，基本问题似乎是——谁负责填充这些字段的业务逻辑，调用者还是服务？

对于我的两分钱，我认为这是服务器的责任，原因有两个。首先也是最重要的 - 安全。客户端脚本本质上是不安全的，因此不应该被信任。例如，有动机的人可以轻松伪造您的审计跟踪，并使其看起来好像是另一个用户执行了该操作。其次，我将审计/id 字段的数量视为横切被调用方法的实际业务目的的逻辑。为了创建一个人，客户端不必知道如何表示 id 的实现细节。

至于使用字典与模型，我认为这是个人喜好。这两种方法都不会强制客户端传递完整的字段集。两者都将支持客户端传递操作的唯一主要字段集的设计。实现到模型或字典中只会丢失您的审计/ID 字段。同样，这两种方法都不需要在服务器端验证只读字段，因为不能保证它们在客户端没有被更改。

于 2012-08-16T17:18:16.790 回答