我們有一個名為messages. 我們想要有兩種方法來列出它的集合。一個只會回傳強制性的并且已經被查看過的訊息；另一個，所有訊息。每個都有另一個不需要的欄位，因此我們不希望回傳它們。例如
一種回應應如下所示：
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
uj5u.com熱心網友回復：
我找不到這種情況的通用規則。那么，哪個選項遵循 REST？
REST不關心您為資源識別符號使用什么拼寫約定。
特別是，機器并不關心識別符號的拼寫是否與資源的語意匹配（提醒：URL 縮短器有效）
/messages/mandatories
/messages?view=mandatories
/messages?mandatoryListing=true
/mandatory-messages
這些都沒問題。
有一些純粹的機械差異；使用 HTML 表單作為 URI 模板時，使用鍵值對進行查詢很方便。當使用點段和相對解析度來描述同一層次結構中的其他識別符號時，路徑層次結構很方便。
識別符號作為文本出現在許多地方——我們將 URI 粘貼到訊息中，它們在瀏覽器歷史記錄中被跟蹤，它們出現在您的訪問日志中。所以我們有很多不同的人在不同的背景關系中查看識別符號。嘗試選擇所有人都能接受的拼寫；但盡可能優化最重要的體驗。
uj5u.com熱心網友回復：
這是基于意見的邊緣，但這就是我要做的。最 RESTful 的方式是使用查詢引數，比如/messages?view=mandatories. 與此有關的問題（可能不是您的用例的問題，您需要考慮）是回應模型需要與 for 相同/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在某些情況下而不是null在其他情況下的屬性。
uj5u.com熱心網友回復：
首先，如果是訊息，那么/messages應該在那里，因為資源是訊息。
在那之后，messages/mandatories意味著有一個強制性串列，它是訊息的一個子集。您是否打算使用 put、post 或 patch 添加或更新強制性訊息，messages/mandatories是正確的方法。
但是，如果它只是對強制性訊息的過濾器，那么最好的方法是使用GET這樣的：/messages?status=mandatories
status指示訊息是否為必填欄位的欄位在哪里
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/363547.html