Rest HATEOAS内容类型：自定义mime类型

我一直在尝试实现RESTFul体系结构，但我完全搞不清自定义媒体类型是好是坏

目前，我的应用程序使用Http-Link:header传递“链接”。这很好，我将其与title属性一起使用，允许服务器描述这个“动作”到底是什么，尤其是当呈现给用户时

我感到困惑的是是否应该指定自定义mime类型。例如，我有一个用户的概念。它可能与当前资源相关联。我要编一个例子，说我有一件拍卖品。我们可能有一个用户在“监视”它。因此，我将包括链接

rel=”http://myapp/watching";title=“Joe Blogg”，methods=“GET”

在标题中。如果您能够将该用户从监视中删除，您将获得

rel=”http://myapp/watching";title=“Joe Blogg”，methods=“GET，DELETE”

我对此很满意，如果客户有正确的角色，他可以解除关系。所以我在定义如何处理一段关系。最妙的是，如果我们在“关系”资源上调用GET，我将客户机重定向到用户资源

让我困惑的是是否使用自定义mime类型。关于这一点，在互联网上和我的头脑中都有争论

我做了一个示例，在这个示例中，我对未知url调用

HEAD

，服务器返回

内容类型：application/vnd.myapp.user

。然后，我的客户机决定它是否能够理解这个mime类型（它维护它所理解的资源到视图的映射），并将遵循它，或者解释它无法理解该链接末尾的内容

这不好吗？。我必须维护特殊的mime类型。特别奇怪的是，我非常乐意使用标准的

应用程序/用户

格式，但在任何地方都找不到指定的格式

我开始认为我应该尝试完全猜测在任何HTTP响应中呈现什么，几乎到了我的RESTFul api应该只是呈现html，而不是尝试使用json/xml

我尝试过搜索（甚至是Roy Fieldings的博客），但是找不到任何描述客户应该如何处理这种情况的内容

---

编辑：包括自定义类型，我的论点是它不一定是一个“用户”在观看该项目，它可能是带有

application/vnd.myapp.group

的东西。通过得到响应，客户机知道主体具有不同的内容，因此更改为显示组的视图。但是这种mime类型与视图的耦合是否不好？

我想说的是，您肯定希望所有表示都有一个特定的媒体类型。如果您可以找到一个标准的（html、jpeg、atom等），请使用它，如果找不到，则应定义一个（或多个）

原因是：表示应该是自包含的。这意味着你的客户从某个地方得到一个链接，它应该知道如何处理它。如何显示它，如何从那里开始，等等。例如，浏览器知道如何显示文本/html。您的客户应该知道如何显示/处理application/vnd.company.user

而且，我认为你的内容谈判是倒退的。您不需要调用HEAD来确定服务器支持什么表示。您可以使用“Accepts”头在GET/POST/etc请求中告诉服务器您的客户机支持什么。事实上，这将是做这件事的标准方式。然后，服务器会对您接受的mime类型给出“最佳”表示。你不需要更多的往返

因此，尽管您提供的链接可以包含上下文信息，通常在“rel”属性中给出，比如链接指向“下一页”、“上一页”、“订阅用户”或“所有者用户”等，但客户端不能在这些链接下采用任何表示。它知道它在语义上是一个“用户”，因此它可以用用户（application/vnd.company.user）支持的所有表示形式填充“Accepts”头。如果表示只表示text/xml，那么客户机就无法假设它可能接收到的内容或链接的语义

在实践中，您当然可以对任何客户机进行编码，使其仅假设在什么链接/URL下有什么表示，并且您不必一直遵守REST，但如果您这样做，您确实会获得很多好处（如Roy Fielding的论文所述）

---

另一个小点是：链接不需要包含给定资源的可用方法，这就是选项的用途。诚然，它很少实现。

您不必发送HTML来服务超媒体。有许多不同的超媒体格式比HTML更容易解析

您不必使用特定于域的MIME类型，在我看来，最好将特定于域的词汇表与通用超媒体类型一起使用，例如微格式或schema.org与JSON-LD+Hydra或ATOM/XML+microdata/RDFa等。。。根据你的口味，有很多选择

---

我不确定向多个方法添加相同的关系是否是一个好的选择。如果需要，可以使用d发送多个具有不同in-link头的链接：

请看，对我来说奇怪的是，客户端，可能还有mime类型几乎必须指定所有可能“监视”的内容。我举了一个关于未来可能会改变“观察”背后的资源的例子，例如一个小组。你说客户端在语义上知道它是用户。。但是它应该吗？。它不应该获取服务器发送回来的mime类型并以这种方式处理它，而不是假设它是一个

应用程序/vnd.app.user

，如果它是另一个也具有这种关系的资源呢？如果不想，您不必指定链接指向用户。但是，你怎么看