我已经开始设计一个API,并决定让它符合REST / HATEOAS。 API的切入点应该是什么?
似乎常见的是GET /
但是根据我的阅读,使用OPTIONS /
在逻辑上更有意义,因为/
实际上没有资源检索。
我在这里给出了两个示例,使用JSON的HAL语法作为超媒体格式。
请求:
GET / HTTP/1.1
Host: example.com
响应:
HTTP/1.1 200 OK
Date: …
Content-Type: application/json;charset=utf-8
Content-Length: 143
{
"_links": {
"self": {
"href": "/"
},
"penguins": {
"href": "/penguins"
}
}
}
请求:
OPTIONS / HTTP/1.1
Host: example.com
响应:
HTTP/1.1 200 OK
Date: …
Allow: OPTIONS
Content-Type: application/json;charset=utf-8
Content-Length: 143
{
"_links": {
"self": {
"href": "/"
},
"penguins": {
"href": "/penguins"
}
}
}
答案 0 :(得分:2)
OPTIONS
请求的响应仅描述您请求的资源的选项,即/
。它通常对GET /
提供更多信息,然后让响应正文中每个链接的链接关系告诉您可以对链接资源采取哪些操作。
此外,对OPTIONS
的回复不可缓存,这可能非常重要,尤其是涉及到像链接菜单这样的静态内容时。
答案 1 :(得分:2)
在这个简单的例子中,我建议使用Link标头:
HTTP/1.1 200 OK
Date: …
Link:</likeapenguinbutopaque>;rel=penguin;type=image/jpeg
使用&#34; rel&#34; attribute还允许指定与链接引用的目标资源的关系。请注意&#34; rel&#34;的语义。必须在当前资源的上下文中进行解释。为了说明这一点,让我们按照链接。应该返回一只企鹅的图片,以及以下链接:
Link : <>; rel=wing;type=image/jpeg
&#34;翼&#34;关系在这里是清楚的:它是当前资源(一只企鹅)和它的OWN翼(不是另一只企鹅的翅膀)之间的关系。这是HATEOAS的神奇(和冗长):每个链接仅在特定资源上下文中使用其含义。 所有这一切都是为了打败在浏览时在特定场合返回的单个文档中描述所有资源树的诱惑。这将是邪恶的,但不是HATEOAS ......
另请注意,HATEOAS在交换JPEG图像时已实现,其媒体类型不是超媒体。链接头,普遍和足够丰富将完成这项工作。 假设您拥有的一些企鹅可以更新:
Link: <>;rel=wing;allow=PUT;type=image/jpeg
将在给定的可更新企鹅的精确背景中发出信号。