我有一个REST语法问题： 您给端点一个什么样的URL，以便从传递的ID中提取类似于记录的数据？
举个例子：我有一个班级记录： 记录{id：12，电话号码：“ + 336746563”}
我想要一个端点，该端点将返回与ID为12的记录共享同一phoneNumber的所有记录
哪个网址最尊重REST协议？
编辑要点：客户端在呼叫URL时不知道电话号码。只有12个ID。
答案 0 :(得分：1)
您给端点提供什么url以提取与传递的id相似的记录数据？
任何您想要的-机器都不会在乎您的资源标识符使用什么拼写。
我想要一个端点，该端点将返回与ID为12的记录共享同一phoneNumber的所有记录
/all-records-with-same-phone-number-as?id=12
/all-records-with-same-phone-number-as?12
/all-records-with-same-phone-number-as/12
所有这些示例都是 fine 。它们有不同的取舍-第一个非常容易使用HTML表单生成。最后一次允许您使用相对引用和点段来做有趣的事情。
/record/12/all-records-with-same-phone-number
与上述类似，我们只是弄乱了路径段的顺序。如果我们希望在相同的/record/12词干下有相对于其他资源的相对引用，则可能会有用。
如果您希望进行分页，那么您可能需要考虑分页参数如何适合其他所有内容。同样，这些机器不在乎，但是某些拼写比其他拼写更容易使用。
答案 1 :(得分：0)
我不确定我是否理解问题，但让我尝试。
您可以采用最适合自己的各种方式来执行此操作。您的编程语言。例如，domain.com/api/records/123456可以作为端点。 123456是一个参数，您的代码将返回所有具有phoneNumber = 123456的记录。
或者，端点可以是domain.com/api/records?phoneNumber=12345。
或者甚至是domain.com/api/records/123456/phonenumber。
另一种选择是将请求数据放在正文中，并且域看起来像domain.com/api/records，请求为{"PhoneNumber":"123456"}
AFAIK，所有这些URL都遵循REST协议。
答案 2 :(得分：0)
我会用类似的东西
/service/records/{id}/similar
服务将在其中定义相似性的地方。当Record变得更复杂并且客户端应该能够指定字段时，这取决于用例。
迟早会导致查询不基于现有记录并且我看起来像
/service/records?foo=1&bar=2
我也可以想到
/service/records/phone-number/12345
因为您真的对具有相同phoneNumber而不是相似性的记录感兴趣？
但是，随着事情变得越来越复杂，我认为使用查询会更好。