在純粹的REST方法中，所有端點（起始端點除外）都是不透明的，不需要發布其各種詳細信息。 即使使用這種方法，本文中的要點也很重要，因為服務器邏輯將必須確定何時需要結束點。

介紹

在REST體系結構中，實體或資源（ 在本文的其余部分將使用術語“實體”）可能具有也可能沒有其自己的地址。 例如，假設我們有一個庫存應用程序，供商人用來銷售其產品。 立即可以看到一個產品實體。 它的URL類似于：/ product / {id}

現在，銷售產品的商人可以將自己的評論添加到產品中。 例如， ”
星期五的銷售情況很好 ”或“ 如果產品沒有開始銷售，請考慮更改價格 ”。 一個產品可以有0 .. *注釋。 如前所述，產品具有自己的地址：/ product / {id}，例如/ product / 1231233

和這樣的響應負載

{"id":"1231233","type":"Beer","comments": [{"id":"1","comment":"Sells very well on Fridays" }, {"id":"2","comment":"Consider changing price if product doesn't start selling" }]}

可以看出，有效負載返回了注釋對象的集合。 每個評論都應該有自己的地址，還是可以將它們嵌入產品響應中？ 為了幫助回答這個問題，應考慮以下內容。

實體在包含實體上下文之外是否有任何意義？

如果實體（例如注釋）在其包含的實體（例如產品）之外具有含義，則它們應具有自己的地址。 例如，假設實體是學生，并且學生返回了他/她所學習的大學列表。 這些大學在學生以外具有自己的含義。 所以很明顯，大學應該有自己的地址。 在“活動/注釋”業務情景中，“注釋”僅針對活動存在。 沒有其他實體會引用它們或需要引用它們。 因此，需要考慮其他方面。

是否需要對單個實體執行操作？

是否應該允許客戶端創建，讀取，更新或刪除單個實體？ 這些必須分開考慮。

寫：創建，更新，刪除

在產品/評論場景中，永遠不會在產品外部或沒有產品的情況下創建評論。 它實際上是添加到產品中的。 這可以視為對產品的部分更新。 但是，對現有注釋的更新或刪除也可以視為產品的部分更新。 這會導致如何使用產品的部分更新來區分創建/更新和刪除注釋之間的復雜性。 如果需要這樣做，則為注釋創建上下文地址（指示產品/注釋的層次結構性質）然后允許客戶端向其發送POST，PUT，PATCH，DELETES會更簡單。

范例網址：/ product / 1231233 / comment / 1

讀

在某些情況下，包含父實體的實體可能不會返回有關子實體的所有信息。 例如，再次考慮產品–>評論場景。 假設評論很大。 這將意味著產品的有效載荷也非常大。 在這種情況下，對于產品而言，僅返回評論摘要，如果客戶希望完整的實體提出單個請求，則可能更為謹慎。 同樣，如果要獲得一個單獨的實體會付出巨大的性能成本（例如，必須調用第三方API來獲取有關注釋的所有信息），那么將URL鏈接發送給實體（而不是而不是實際實體的內容。

N + 1問題

如果需要進行個別讀取，請注意不要引起N + 1問題。 例如，假設一個產品可能有100條注釋。 如果客戶需要所有信息，則Product API將僅返回Comment的摘要以及指向每個評論的鏈接。 但是，如果客戶端希望每個注釋，則意味著現在將有100個HTTP請求。 如果這是一種可能的情況，則應考慮將所有評論匯總到產品中的輔助端點。 這類似于API網關模式。

端點表面積

在任何發布合同的體系結構中，如果合同過多，開發人員就很難理解。 大多數知名的API（例如PayPal，Amazon，Twitter，Google）通常只有大約20-30個地址。 這是一個好目標。 如果有5,000個不同的地址，它可能會變得太大而難以控制等。

總之，決策圖提供了有關您應該做什么的指南。

翻譯自: https://www.javacodegeeks.com/2018/01/rest-resource-get-address.html

總結

以上是生活随笔為你收集整理的REST资源何时应获得其自己的地址？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。