在微服務領域中是否可以進行Hypermedia Driven RESTFul服務？

Question

可以說我們正在創建一個票務處理系統。 假設此域內有兩個不同的有界上下文。 取消票更改票

據我了解，這兩個可以是兩個不同的微服務，而不必彼此了解。 取消服務的票證與更改服務的票證可能完全不同。

從REST API設計的角度來看，我已經閱讀了很多有關使用超媒體並通過將相關操作作為REST響應中的鏈接包括在內來讓客戶端發現資源的信息（ Stefan Tilkov的Talk ）。 如果是這樣，當我的變更服務返回響應時，包含指向取消服務的鏈接是有意義的，客戶端可以使用該鏈接執行取消。 當“取消”和“更改”是兩個彼此都不知道的微服務時，如何實現？ 還是我的局限性錯了？

通常使用微服務時，我們是否會失去這些超媒體鏈接功能（或者變得更難）？

謝謝凱

Answer 1

在HATEOAS中，URI是可發現的（但未記錄），因此可以對其進行更改。 也就是說，除非它們是您系統的最切入點（ Cool URI ，這是唯一可以由客戶端進行硬編碼的URI ），並且如果您想要擴展其余部分的功能，則不應有太多將來您系統的URI結構。 實際上，這是REST最有用的功能之一。

對於其余的非Cool URI，可以隨時間更改它們，並且您的API文檔應闡明以下事實：應在運行時通過超媒體遍歷發現它們。

話雖如此，在您的方案中，該鏈接將是一個很酷的URI，而不是相對於當前API的鏈接（因為它可能位於其他機器/域等上）。 除非您使用某些發現工具 ，否則您將不得不對該鏈接進行硬編碼，從而失去可發現性的好處。