在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？
答案 0 :(得分：0)
之前我没有听说过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 ++中的模板），但这是最“安全”和“便携式“可以描述您与客户的界面。