Web服务 – 用于多个依赖资源的REST-ish URI设计

概述我正在尝试设计一个基于REST-ish的Web服务来与我正在研究的农场动物管理系统进行交互. 为了详细解释这个问题,我收集了一个属于农场的动物.每只动物都有自己的信息 – 例如姓名,身份z号码,品种年龄等.因此,我会假设如下所示的URI适合： /animals <- retrieve list of animals/animals/{animal-id} <- R 我正在尝试设计一个基于REST-ish的Web服务来与我正在研究的农场动物管理系统进行交互.

为了详细解释这个问题,我收集了一个属于农场的动物.每只动物都有自己的信息 – 例如姓名,身份z号码,品种年龄等.因此,我会假设如下所示的URI适合：

/animals               <- retrIEve List of animals/animals/{animal-ID}   <- RetrIEve only one animal/animals?breed=sheep   <- Search/query

当我尝试将其他依赖资源链接到每只动物时,问题就出现了.动物可以拥有一系列体重信息,以及我所说的评论(针对特定动物的观察).这些中的每一个都是依赖的,并且只存在于那个特定的动物中,但它们本身就是我想要访问的资源.

IMO最简单的方法是将资源嵌套在动物URI中：

/animals/{animal-ID}/weights/animals/{animal-ID}/comments

但是,我发现需要直接访问和查询权重和注释,而无需引用动物.在使用的例子是从特定品种…？品种绵羊=,甚至返回的权重/提供意见,选择个体动物ID的……？动物的所有动物获取最新的(或全部)重量(S) = {ID1},{} ID2,{…}.

当我想一次向多个动物添加一条评论时,会出现更多复杂情况. (请原谅我对POST和JsON的陈述)

POST ....{  "comment":"Animal moved to paddock B","animals":[{ID1},{ID2},...]}

我知道这个问题的明显解决方案是对我想要检索/编辑的每只动物进行GET和POST(例如).我宁愿不这样做,因为最终我希望从移动设备访问这项服务,因此减少通话次数似乎是明智之举.

我相信网络标准允许在URI中使用CSV,所以这样的东西可以工作,

/animals/{ID1},{..}/weights

但是,我期待一次(或查询)需要引用十(10)只动物的情况,这将导致一个混乱且不友好的URI.

我目前认为的解决方案是将权重和注释作为自己的资源公开,这允许我直接访问和查询它们

/weights/weights/{weight-ID}/weights?breed=sheep

甚至直接发布到收藏品

POST /comments{  "comment":"Animal moved to paddock B",...]}

但是/ animals / {animal-ID} / weight会返回什么？它是否需要,或者我只是引用/ weights？animal = {animal-ID}资源本身的链接？但链接到查询资源是否可以？

我是在制作一个多余的,还是只提供“另一种”方式来访问信息？

有什么东西我做错了,我让我的数据库影响我的服务模型,还是我完全忽略了这一点？

我对此很陌生,并且已经阅读了很多关于这些问题的矛盾论点,因此对于什么对我的要求最好是非常困惑的.

谢谢！

解决方法 如果您想要为其他实体定义顶级资源(/ weight,/ comments等),那么最好为其他实体定义顶级资源.然后,您可以批量方式POST到这些端点.

POST /comments{    "animals" : [        {"ID" : 1},{"ID" : 2},{"ID" : 3},{"ID" : 4},],"commentText" : "Sent to Hamburger Hamlet"}

请注意,由于多种原因,包括大多数浏览器和HTML代理都限制了网址长度(包括大多数浏览器和HTML代理都限制了网址长度)(包括大多数经验法则都是尝试将网址长度设置为2083个字符或更短).

总结

以上是内存溢出为你收集整理的Web服务 – 用于多个依赖资源的REST-ish URI设计全部内容，希望文章能够帮你解决Web服务 – 用于多个依赖资源的REST-ish URI设计所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。