8

我已经开始设计一个 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"
        }
    }
}
4

2 回答 2

2

请求的响应OPTIONS仅描述您请求的资源的选项，即/. 它通常会提供更多信息GET /，然后让响应正文中每个链接的链接关系告诉您可以对链接资源采取哪些操作。

此外，对的响应OPTIONS是不可缓存的，这可能非常重要，尤其是在涉及静态的东西（如链接菜单）时。

于 2013-10-30T04:56:01.450 回答
2

在这种简单的情况下，我建议使用 Link 标头：

HTTP/1.1 200 OK
Date: …
Link:</likeapenguinbutopaque>;rel=penguin;type=image/jpeg

“rel”属性的使用还允许指定与链接引用的目标资源的关系。请注意，“rel”的语义必须在当前资源的上下文中进行解释。为了说明这一点，让我们点击链接。应该返回企鹅的图片，以及以下链接：

Link : <>; rel=wing;type=image/jpeg

“翅膀”关系在这里很清楚：它是当前资源（企鹅）与其 OWN 翅膀（不是另一只企鹅的翅膀）之间的关系。这就是 HATEOAS 的魔力（和冗长）：每个链接仅在特定的资源上下文中才有意义。所有这些都是为了克服在浏览时在给定场合返回的单个文档中描述所有资源树的诱惑。这将是邪恶的，呃，不是 HATEOAS...

另请注意，HATEOAS 是在交换 JPEG 图像时实现的，其媒体类型不是超媒体。链接标题，普遍且足够丰富将完成这项工作。假设您拥有的一些企鹅可以更新：

Link: <>;rel=wing;allow=PUT;type=image/jpeg

将在给定的可更新企鹅的精确上下文中发出信号。

于 2015-04-02T16:02:56.717 回答