Question

在Web应用程序中有3个下拉选择器。 Web应用程序使用Restful服务来填充选择器数据。

两个第一个选择器从/years和/colors获取其值。第三个应该根据两者的设置得到它的值。

所以它可能像/models?year=1&color=red。

问题是，如何使这个符合HATEOAS标准（以便开发人员不必知道他应该如何创建一个url来获取模型）。

根/为我提供了许多链接，例如：

{
"_links": {
      "colors": "/colors",
      "years": "/years",
      "models": "???" }
}

应该是什么而不是???？如果存在某种模板/models?color={color}&year={year}，则开发人员必须创建该URL。这样好吗？

或者可以链接到从/colors获得的每种颜色的年份列表，然后从/years?color=red获得每年的模型列表链接，但我必须首先选择颜色，然后填充多年，然后填充模型。如果我想让模型依赖于颜色和年份，而不仅仅是从颜色填充的那一年？

在这种情况下是否有可能使其符合hateoas？

Answer 1

之前我没有听说过HATEOAS，但基于我刚刚读到的内容，它似乎应该返回指向服务消费者可以在“状态机”中前进的链接。

在您的情况下，将转换为“函数调用”的链接。前两个（/colors和/years）是不带参数的函数（此时返回“某些东西”），而第三个函数调用带有两个参数：一个是表示一种颜色，另一种颜色。对于前两个具有简单URL的链接就足够了，但对于第三个，您还需要包含参数名称/类型信息。类似的东西：

{
  "_links": {
    "colors": "/colors",
    "years": "/years",
    "models": {
      "url": "/models",
      "param1": {"color"}
      "param2": {"year"}
    }
  }
}

注意：您也可以使用与“颜色”和“年”相同的“模型”布局。

此时，客户端知道访问函数的URL是什么以及将参数（如果有）名称传递给函数。

还缺少一件事：类型。虽然你可以只使用“string”，但“color”参数实际上是“/ colors”返回的值并不明显。您可以引入描述颜色的“类型”颜色（以及对颜色进行操作的任何函数：提供可显示的名称，HTML颜色代码等）。

“强化”签名变为：

{
  "_links": {
    "colors": {
      "url": "/colors",
      "return": "/type/List?type=/type/Color"
    },
    "years": {
      "url": "/years",
      "return": "/type/List?type=/type/Integer"
    },
    "models": {
      "url": "/models",
      "param1": {
        "name": "color",
        "type": "/type/Color"
      },
      "param2": {
        "name": "year",
        "type": "/type/Integer"
      }
      "return": "/type/List?type=/type/Model"
    }
  }
}

注意：路径“/ type”仅用于将类型与函数分开，但不是必需的。

这将可互换且可发现地描述函数，它们采用什么参数以及它们返回的值，因此您可以在正确的位置使用正确的值。

当然在服务端实现这一点并不容易（特别是对于参数化类型，比如“/ type / List” - 想想Java中的Generics或C ++中的模板），但这是最“安全”和“便携式“可以描述您与客户的界面。

RESTful主/细节

1 个答案: