RESTful主/细节

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了，但我必须首先选择颜色，然后填充年，然后填充模型。任何想法，如果我想让模型依赖于颜色和年份，而不仅仅是从颜色填充的年份？

在这种情况下甚至有可能使其符合仇恨条件吗？

Answer 1

我以前没有听说过HATEOAS，但是根据我刚刚阅读的内容，似乎它应该返回链接，指向服务的使用者可以在“状态机”中前进的地方。

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

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

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

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

还有一件事是缺少的：类型。虽然你可以使用“字符串”，但“颜色”参数实际上是“/ 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中的泛型或者C++中的模板），但这是最“安全”的“便携”的方式可以描述你的客户界面。