public class Thing1 : Resource {
public string ABC {get;set;}
public string DEF {get;set;}
}
资源是基类：
public class Resource {
public List<Link> Links {get;set;}
}
哪里的链接,反过来,只是绑定rels和uris.以这种方式,每个资源都具有到其他资源等的链接,消费者可以浏览服务提供的各种资源.
一些(但不是全部)资源是可编辑的,因此消费者将检索资源,对其进行更改,然后将这些更改返回给服务.当然,在这一点上,服务将根据需要执行验证(并处理任何并发问题).
但是,一如以往,如果消费应用程序在尝试PUT请求之前可以执行一些验证,可以减少不必要的往返行程(与使用JavaScript验证的方式大致相同,即使服务器必须重复).
所以,我想在我们的回复中包含一些验证信息,以便消费应用程序知道(例如)ABC不能超过6个字符.应该注意的是,目前消费者可以使用相同的资源类(它们在一个单独的程序集中以及适当的MediaTypeFormatter类) – 添加属性(例如System.ComponentModel.DataAnnotations.RequiredAttribute)感觉错误,因为消费应用程序最终会验证是在他们参加共享大会的时候,而不是现在在服务中.
还有一些验证是基于更多的策略,其中在运行时无法计算实际的验证属性.
TL;博士;
在REST响应中包含“有用的”验证信息以及实际资源是一个好的设计,以便消费应用程序可以建立良好的用户体验？
解决方法
> GET /api/Thing/1
< 200 OK
< Content-Type: application/vnd.acme.resource+xml
<resource>
<ABC>blah</ABC>
<DEF>blurg</DEF>
<links>
<links rel="help" href="/api/help/things"/>
<links rel="http://acme.com/rels/validationrules" href="/api/validationrules/things"/>
</links>
</resource>
> GET /api/validationrules/things
< 200 OK
< Content-Type: application/vnd.acme.validationrules+xml
<rules resourceType="thing">
<property name="ABC" MaxLength="6"/>
<property name="DEF" MaxLength="8"/>
</rules>
我在自己的API中做类似的事情.不幸的是没有标准的媒体类型,我意识到这一尝试来解决这个特殊需要.我怀疑尝试定义这种类型的媒体类型会导致“厨房水槽”效应,每个人都有不同的要求,并且它们都被投入,最终的结果是对每个人来说都太复杂了.
但是,根据您的特定需求定义您自己的媒体类型可能是一个非常易于管理的挑战.
在我看来,这个解决方案的重要事情是/ api / validationrules /事情应该很少变化,因此可以由客户端私下缓存.这意味着客户支付非常低的成本,用于将这些信息视为不同的资源.
