我正在实现RESTful API,我不确定"社区接受"行为是否存在无法更改的数据.例如,在我的API中有一个"文件"资源,在创建时包含许多在创建后无法修改的字段,例如文件的二进制数据,以及与之关联的一些元数据.此外,'文件'可以有书面描述和相关标签.
我的问题涉及对这些"文件"资源之一进行更新.特定"文件"的GET将返回与文件关联的所有元数据,描述和标签,以及文件的二进制数据.特定"文件"资源的PUT是否应包含"只读"字段？我意识到它可以用任何一种方式编码:a)包括PUT数据中的只读字段,然后验证它们与原始数据匹配(或发出错误),或b)忽略PUT数据中只读字段的存在因为它们无法更改,如果它们不匹配或丢失则永远不会发出错误,因为逻辑会忽略它们.
似乎它可以采用任何一种方式并且可以接受.忽略只读字段的第二种方法可以更紧凑,因为API客户端可以跳过发送只读数据(如果需要); 这对那些知道自己在做什么的人来说似乎很好......
lim*_*imc 15
就个人而言,两种方式都是可以接受的....但是,如果我是你,我会选择选项A(检查只读字段以确保它们不会被更改,否则会抛出错误).根据项目的范围,您无法深入了解消费者对Restful WS的了解,因为他们中的大多数都不会阅读文档或WADL,即使他们是经验丰富的文档.:)
如果您没有立即向消费者反馈某些字段是只读的,那么他们将错误地假设您的Web服务将在不进行双重检查的情况下处理他们所做的所有更改,或者一旦他们发现"不一致" "更新,他们向其他人抱怨你的网络服务有问题.
如果只读字段与原始值不匹配,您可以通过两种不同的方式处理此问题...
dth*_*rpe 15
除非只读数据构成数据的重要部分(极端情况下,传输只读数据会对网络流量和响应时间产生明显影响),您应该编写服务以接受数据中的只读字段. PUT并检查它们的变化.让相同的数据进出是更简单的.
以这种方式看待它:您可以在PUT中包含可选的只读字段,但您仍然必须/应该在服务中编写代码以检查所接收的任何只读字段是否包含预期值.您必须以任何方式编写只读检查.
禁止PUT中的只读字段是一个坏主意,因为它将要求客户端去掉他们在GET中收到的字段.这要求客户端更加密切地参与您的数据和语义,而不是真正需要的.客户会认为这是一个令人头痛的问题,一个不必要的并发症,以及你加重他们负担的彻头彻尾的意思.从您的GET收到的数据,修改一个感兴趣的领域,并通过PUT将其发回给您应该是客户端的一个脑死亡的简单往返.当你不需要时,不要复杂化.
| 归档时间： |
|
| 查看次数： |
5876 次 |
| 最近记录： |