在REST中，我们如何处理return一个资源集合的多种方式？

Question

我们有一个名为 messages 的资源。我们希望有两种方式来列出其集合。一个会 return 只显示必填且已查看的消息；另一个，所有消息。每个都有另一个不需要的字段，因此我们不想 return 它们。例如

一个回复应该是这样的：

public class MessageListingResponse {
    private Long messageId;
    private String title;
    private String imageUrl;
    private LocalDateTime createdAt;
    private Boolean isViewed;
}

另一个是这样的：

public class MandatoryMessageListingResponse {
    private Long messageId;
    private String title;
    private String imageUrl;
    private LocalDateTime createdAt;
    private String description;
}

我找不到这种情况的通用规则。那么，哪个选项遵循 REST？

/messages/mandatories
/messages?view=mandatories
/messages?mandatoryListing=true
/mandatory-messages

Answer 1

首先，如果是消息，那么/messages应该在那里，因为资源是消息。

之后，messages/mandatories 表示有一个强制性列表，它是消息的一个子集。您是否打算使用 put、post 或 patch 添加或更新强制消息，messages/mandatories 是正确的方法。

但是，如果它只是强制性消息的过滤器，那么最好的方法是使用 GET，如下所示：/messages?status=mandatories

其中 status 是指示消息是否必填的字段

Answer 2

这是基于边缘意见的，但这是我会做的。最 RESTful 的方式是使用查询参数，比如 /messages?view=mandatories。这个问题（对于您的用例可能不是问题，您需要考虑一下）是响应模型需要与 /messages 相同，这意味着您需要有一个模型如下（合并 MessageListingResponse 和 MandatoryMessageListingResponse）：

public class MessageListingResponse {
    private Long messageId;
    private String title;
    private String imageUrl;
    private LocalDateTime createdAt;
    private Boolean isViewed;
    private String description;
}

如果不需要（我也会避免它），那么我会采用不太 RESTful 的方法，例如 /messages/mandatories。不是这样 RESTful 因为 messages 是你的资源，下面的路径信息应该是一个ID，这样你就只能得到一条消息。另一种可能性是像 /messages/view:mandatories 这样的东西，我知道这对大多数人来说可能看起来很奇怪。无论您使用什么结构，通过这种方法，您都可以获得为此拥有特定模型的好处，因此您可以为每个端点拥有非常特定的模型，避免在某些情况下 null 而不是 [=18= 的属性] 在另一个.

Answer 3

I could not find a common rule for this scenario. So, which option follows REST?

REST 不关心您对资源标识符使用的拼写约定。

特别是，机器不关心标识符的拼写是否与资源的语义匹配（提醒：URL shorterers work）

/messages/mandatories
/messages?view=mandatories
/messages?mandatoryListing=true
/mandatory-messages

这些都很好。

存在一些纯粹的机械差异；使用 HTML 形式作为 URI 模板时，使用键值对进行查询很方便。当使用点段和相对分辨率来描述同一层次结构中的其他标识符时，路径层次结构很方便。

文本标识符出现在许多地方 - 我们将 URI 粘贴到消息中，它们在浏览器历史记录中被跟踪，它们出现在您的访问日志中。所以我们有很多不同的人在不同的上下文中查看标识符。尝试选择对所有人都可以接受的拼写；但尽可能优化最重要的经验。

在REST中，我们如何处理return一个资源集合的多种方式？

In REST, how do we deal with multiple ways to return a resource collection?

spring

api

rest

architecture