rest資源設(shè)計(jì)

在純粹的REST方法中，所有端點(diǎn)（起始端點(diǎn)除外）都是不透明的，因此不需要發(fā)布其各種詳細(xì)信息。 即使使用這種方法，本文中的要點(diǎn)也很重要，因?yàn)榉?wù)器邏輯將必須確定何時(shí)需要結(jié)束點(diǎn)。

介紹

在REST體系結(jié)構(gòu)中，實(shí)體或資源（ 對(duì)于本文的其余部分將使用術(shù)語“實(shí)體”）可能具有也可能沒有其自己的地址。 例如，假設(shè)我們有一個(gè)庫存應(yīng)用程序，供商人用來銷售其產(chǎn)品。 立即可以看到一個(gè)產(chǎn)品實(shí)體。 它的URL類似于：/ product / {id}

現(xiàn)在，銷售產(chǎn)品的商人可以將自己的評(píng)論添加到產(chǎn)品中。 例如， ”
“ 星期五 賣得 很好 ”或“ 如果產(chǎn)品沒有開始銷售，請(qǐng)考慮更改價(jià)格 ”。 一個(gè)產(chǎn)品可以有0 .. *注釋。 如前所述，產(chǎn)品具有自己的地址：/ product / {id}，例如/ product / 1231233

和這樣的響應(yīng)負(fù)載

{"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" }]}

可以看出，有效負(fù)載返回Comment對(duì)象的集合。 每個(gè)評(píng)論都應(yīng)該有自己的地址，還是可以將它們嵌入產(chǎn)品響應(yīng)中？ 為了幫助回答這個(gè)問題，應(yīng)考慮以下內(nèi)容。

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

如果實(shí)體（例如注釋）在其包含的實(shí)體（例如產(chǎn)品）之外具有含義，則它們應(yīng)具有自己的地址。 例如，假設(shè)實(shí)體是學(xué)生，并且學(xué)生返回了他/她所學(xué)習(xí)的大學(xué)列表。 這些大學(xué)在學(xué)生之外具有自己的含義。 因此，顯然大學(xué)應(yīng)該有自己的地址。 在“活動(dòng)/注釋”業(yè)務(wù)情景中，“注釋”僅針對(duì)活動(dòng)存在。 沒有其他實(shí)體會(huì)引用它們或需要引用它們。 因此，需要考慮其他方面。

是否需要對(duì)單個(gè)實(shí)體執(zhí)行操作？

是否應(yīng)該允許客戶端創(chuàng)建，讀取，更新或刪除單個(gè)實(shí)體？ 這些必須分開考慮。

寫：創(chuàng)建，更新，刪除

在產(chǎn)品/評(píng)論場(chǎng)景中，永遠(yuǎn)不會(huì)在產(chǎn)品外部或沒有產(chǎn)品的情況下創(chuàng)建評(píng)論。 它實(shí)際上是添加到產(chǎn)品中的。 這可以視為對(duì)產(chǎn)品的部分更新。 但是，對(duì)現(xiàn)有注釋的更新或刪除也可以視為產(chǎn)品的部分更新。 這會(huì)造成如何使用產(chǎn)品的部分更新來區(qū)分創(chuàng)建/更新和刪除注釋的復(fù)雜性。 如果需要這樣做，則為注釋創(chuàng)建上下文地址（指示產(chǎn)品/注釋的層次結(jié)構(gòu)性質(zhì)）然后允許客戶向其發(fā)送POST，PUT，PATCH，DELETES會(huì)更簡(jiǎn)單。

范例網(wǎng)址：/ product / 1231233 / comment / 1

讀

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

N + 1問題

如果需要單獨(dú)讀取，請(qǐng)注意不要引入N + 1問題。 例如，假設(shè)一個(gè)產(chǎn)品可能有100條注釋。 如果客戶需要所有信息，Product API將僅返回Comment的摘要以及指向每個(gè)評(píng)論的鏈接。 但是，如果客戶端希望每一個(gè)注釋，則意味著現(xiàn)在將有100個(gè)HTTP請(qǐng)求。 如果這是一種潛在的情況，則應(yīng)考慮將所有評(píng)論匯總到產(chǎn)品中的輔助端點(diǎn)。 這類似于API網(wǎng)關(guān)模式。

端點(diǎn)表面積

在任何發(fā)布合同的體系結(jié)構(gòu)中，如果合同太多，開發(fā)人員就很難理解。 大多數(shù)知名的API（例如PayPal，Amazon，Twitter，Google）通常只有大約20至30個(gè)地址。 這是一個(gè)好目標(biāo)。 如果有5,000個(gè)不同的地址，它可能會(huì)變得太大而難以控制等。

總之，決策圖提供了有關(guān)您應(yīng)該做什么的指南。

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

rest資源設(shè)計(jì)

總結(jié)

以上是生活随笔為你收集整理的rest资源设计_REST资源何时应获得其自己的地址？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。