是否有可能在微服務世界中執行超媒體驅動的RESTFul服務？

Question

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

從我所瞭解的情況來看，這兩個可以是兩個不同的微服務，而不必相互認識。 「取消」服務的票證與「更改」服務的票證完全不同。

從REST API設計的角度來看，我讀了很多關於使用超媒體，讓客戶通過包括相關經營爲REST響應（Stefan Tilkov's Talk）內的鏈路資源發現。如果那是真的，當我的變更服務返回響應時，包含一個到取消服務的鏈接是合理的，客戶可以使用它來執行取消。當取消和更改是兩個不同的微服務時，我怎麼能達到這個目的呢？或者我的有限上下文是錯誤的？

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

感謝 凱

Answer 1

在HATEOAS URI是發現（而不是文檔），以便它們可以改變的。也就是說，除非它們是你係統的入口點（Cool URIs，唯一可以由客戶端硬編碼的） - 如果你想讓你的其餘部分能夠進化，你就不應該有太多這樣的入口點系統的URI結構。這實際上是REST的最多useful功能之一。

對於其餘的非酷URI，它們可以隨時間改變，並且您的API文檔應該明確應該通過超媒體遍歷在運行時發現它們的事實。

這就是說，在你的情況下，鏈接將是一個酷URI，而不是相對於當前的API（因爲它可能駐留在不同的機器/域等）。除非您使用某些discovery tool，否則您將不得不硬編碼該鏈接，從而失去可發現性的好處。