我在为域中的资源建模以适应REST API时遇到了一些问题。这个例子显然是人为设计和简化的，但它说明了我陷入困境的2点。
我知道：
- 用户有宠物
- 宠物有多个名字，每个家庭成员都有一个
- 宠物有：出生日期、死亡日期和类型（狗、猫…）
- 我需要能够根据日期进行查询（实际上，当询问宠物时，日期或日期范围是强制性的）。例如：告诉我我现在养了什么宠物；告诉我奶奶说我们5年前到3年前养了什么宠物
我应该如何处理日期
a。在查询字符串中：/pets/dogs/d123？从＝10102010&to=10102015（但据我所知，查询字符串主要用于可选参数；需要日期/日期范围。如果查询字符串中没有任何内容，我想将当前日期作为默认日期。对此有什么想法吗？）
b。在路上的某个地方。之前/宠物？当我在一个日期和一系列日期之间切换时，这似乎有点奇怪。我真正的道路已经有点长了
我应该如何处理多个名称
在我看来，我必须指定谁使用我正在搜索的名称。
/宠物/狗/雷克斯->我想知道一只叫雷克斯的狗（是谁，是我还是奶奶？）。但是把奶奶放在哪里呢？
我看到一些人说不要担心url，而是使用超媒体。但我理解的方式（可能我只是弄错了）是，你必须始终从根（here/pets）开始，并遵循响应中提供的链接。然后我就更困了（因为约会的可能性真的很长）。
感谢您的帮助。感谢
在这种场景中可能有用的是一种资源查询语言。它不知道您使用的技术堆栈，但可以在这里找到一个JavaScript示例。
-
绝对不要在路上放任何日期。这被认为是一种糟糕的风格，用户可能会感到困惑，因为他们中的大多数人可能不习惯这种奇怪的设计，根本不知道如何使用API。通过查询字符串传递日期是非常好的。您可以引入默认状态-这不是一个坏主意-但您需要在响应中描述状态（例如，包括日期）。当请求中缺少日期范围时，您也可以返回
400 Bad Request状态代码。就我个人而言，我会通过查询字符串选择默认状态和日期。 -
在这种情况下，我唯一想到的就是扭转这种关系，所以它会是：
/users/grandma/dogs/rex或：
/dogs/rex/owners/grandma -
还可以做的是放弃REST规则，引入新的端点
/dogs/filter，它将接受主体中带有过滤器的POST请求。这样一来，描述整个查询以及发送查询都会容易得多。正如我所提到的，这不是RESTful方法，但在这种情况下似乎是合理的。这种过滤也可以用纯REST设计建模——过滤器也将成为一种资源。
在这种特殊的情况下，超媒体似乎不是一条路——老实说，我不太喜欢超媒体设计。
如果需要，可以使用查询字符串，没有任何限制。路径包含层次结构，而查询包含非层次结构部分，但这也不是强制性的。
通过查询，我建议您考虑参数以及响应中的内容。例如：
我想知道一只叫雷克斯的狗（是谁，我还是奶奶？）
参数为：rex和grandma，响应中需要dog s。
因此，超链接将类似于GET /pets/dogs/?owner=grandma&name=rex或GET /pets/dogs/owner:grandma/name:rex/等。如果您将一些RDF元数据附加到超链接和参数，则URI结构并不重要。例如，您可以使用https://schema.org/AnimalSheltervocab。Ofc。这不是最适合的，因为它不关心多个人给出的多个名字，但如果您决定使用RDF，这是创建自己的vocab的一个良好开端。