当我在设计REST API时，我有一个疑问。
假设我有一个资源客户;我的服务器中有两个元素，如下所示:
[
{
name : "Mary",
description : "An imaginary woman very tall."
},
{
name : "John",
description : "Just a guy."
}
]
我想创建一个端点，它将接受带有查询的GET请求。查询将提供一个参数，该参数的值将使算法计算该文本在其所有参数中出现的次数。
所以如果我们抛出这个请求:
{baseURL}/客户吗?字母
=变化中我应该得到像
这样的东西[
{
name : "Mary",
description : "An imaginary woman very tall.",
count : 3
},
{
name : "John",
description : "Just a guy.",
count : 0
}
]
Count参数不能包含在资源方案中，这取决于查询中提供的值，因此必须对响应对象进行充实。
我得到的不是我的资源列表，而是一个修改过的资源。
虽然它保持了GET方法的幂等条件，但我认为它逃避了REST体系结构概念(甚至是超越CRUD的REST)。
在RESTful API中仍然是一个有效的端点吗?还是应该创建一个名为"ratedcustomer"的新资源?
REST GET方法:是否可以返回一个富集资源列表?
TL;博士:是的。
再回答…
成功的GET请求返回由请求目标标识的单个资源的表示形式。
用于创建资源表示的信息来自域模型中的多个实体，或数据库中的多个行，或来自其他服务生成的报告……这些都是实现细节。通过网络应用程序传输文档的HTTP不关心。
这也意味着我们可以有多个资源，在它们的表示中包含相同的信息。想想维基百科里的"页面"互相复制信息
web上的资源标识符在语义上是不透明的。这三个标识符被理解为不同的资源/A
/A?enriched
/B
我们人类看着这些标识符可能会期望/A?enriched在语义上更接近/A而不是/B，但机器不会做出这样的假设。
对于/A?enriched来说，使用不同的模式甚至不同的内容类型生成表示是完全合理的(就HTTP应用程序而言，/A是HTML文档，/A?enriched是图像是完全合理的)。
因为机器不关心，您在如何设计资源和资源标识符方面有了额外的自由度，您可以使用这些自由度来享受额外的好处，包括设计一个易于实现的模型，或易于记录，或易于接口，或易于监控，或....
设计是我们为了得到更多我们想要的东西而做的事情。