Spring HATEOAS

或許你會覺得這又是啥?

其實是 Hypermedia as the Engine of Application State 縮寫啦.

那這個在 Spring Data 裡面你只要是用 @RepositoryrestResource 他回傳的就是這個格式, 這邊還有個好處是, 你只要使用 SpringData 操作的不管是 MongoDB ElasticSearch 還是 傳統資料庫, 他提供的 Rest API 就是這個相同的結構, 你們前端也不用 呼天喊地 辛苦的接不同格式資料.

好了那實際上有什麼差別? 又要用在哪個時間點?

好了舉例來說這是我們傳統回覆給前端資料庫裡面的一列資料

{
  "name": "Alice"
}

下面則是帶有 HATEOAS 格式的結構

{
  "studentid": "65874115",
  "name": "Alice",
  "classid": "6866",
  "_links": {
    "self": {
      "href": "http://localhost:8080/student/65874115"
    },
    "class": {
      "href": "http://localhost:8080/class/6866"
    }
  }
}

關於這個學生的相關資料, 如 在哪一班?
前端只需要從 _links 抽出 class 這個資訊位置, 再去呼叫就可以取得相關資料了.

你也許會想說, 啊脫褲子放屁....都有 classid 了前端知道位置自己去查就好啦....

But... 人生最厲害就是這個But....

若是還要考慮到 API 版本的控管勒?

那你前端不就改到瘋掉 每次都改 v -> v2 -> v3 再上架....

你早晚會被前端砍

但如果你可以提供這個的資訊.

{
  "studentid": "65874115",
  "name": "Alice",
  "classid": "6866",
  "_links": {
    "self": {
      "href": "http://localhost:8080/api/v1/student/65874115"
    },
    "class": {
      "href": "http://localhost:8080//api/v2/class/6866"
    }
  }
}

在資料格相容的情況下 _links.class 指的位置不一樣, 對前端來說他就完全不需要去修正他的 程式 或 url 定義等等....

這不是皆大歡喜.....XD