【问题标题】:Content negotiation and extended media types内容协商和扩展媒体类型
【发布时间】:2014-11-15 20:47:14
【问题描述】:

某些媒体类型是其他媒体类型的扩展。此类媒体类型通常在其名称中使用 + 来表示这一点。例如,application/atom+xml 扩展通用 xml,application/hal+json 扩展通用 json。

我的问题是:如果客户端请求通用媒体类型并且服务器想要使用扩展媒体类型之一进行响应,应该怎么做?例如,如果一个请求的 header 为 Accept: application/json,并且服务器想要以 application/hal+json 响应,那么服务器应该...

  1. ...提供带有Content-type: application/json 的纯简JSON,即不包括_links_embeddeds?这就是客户要求的,这就是它得到的。如果您想要 HAL,请索取。

  2. ...使用 Content-type: application/json 提供 HAL 表示? HAL,毕竟是 json,这就是客户要求的。客户很高兴,可以忽略它不理解的部分。

  3. ...使用Content-type: application/hal+json 提供 HAL 表示?像 2. 一样,客户端得到它想要的并且可以忽略它不理解的位。但也有一条线索表明,客户可以从表示中获得更多收益。

我的偏好是 3。但是是否有规范、最佳实践或常用方法可以提供指导,这是最佳选择?

【问题讨论】:

    标签: http content-negotiation


    【解决方案1】:

    服务器可以做这三个中的任何一个,或者如果它不愿意用默认表示来响应,它可以用406 Not Acceptable 来响应。

    见:https://www.rfc-editor.org/rfc/rfc7231#section-6.5.6

    【讨论】:

    • 感谢您提供指向 RFC 7231 的链接。我一直坚持我的 RFC 2616 打印输出已经太久了。我只是把它扔掉并打印了这个和它的同伴。现在,如果我可以停止粘在纸上:-)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-08-06
    • 2012-03-30
    • 2015-01-31
    • 2015-06-28
    • 2013-07-30
    • 2010-12-26
    相关资源
    最近更新 更多