URL查询参数或媒体类型参数(在Accept标头中)配置对HTTP请求的响应？

Question

我正在设计一个可以使用各种格式进行响应的REST API,其中一种格式是纯文本格式,可以配置为显示或隐藏响应中的某些方面(例如章节标题或脚注).完成此操作的传统方式是通过URL查询参数,以指示所需的响应类型和配置选项,例如:

http://api.example.com/foo-book/ch1/?format=text&headings=false&footnotes=true

但是,更优雅的RESTful方式来指示所需的响应类型(而不是format=textURL查询参数)是使用Accept标头,例如:

Accept: text/plain; charset=utf-8

现在,除了URL之外,媒体类型可以根据RFC 2046获取参数,如普遍存在text/html; charset=utf-8和Accept标题中所示audio/*; q=0.2.它还表明供应商制作的MIME类型可以定义自己的参数,如:

application/vnd.example-com.foo+json; version=1.0
application/vnd.example-info.bar+xml; version=2.0

因此,对于以前注册的MIME类型,如text/html或application/json,是否可以包含应用程序需求的自定义参数？例如:

Accept: text/plain; charset=utf-8; headings=false; footnotes=true

这似乎是一个优雅的RESTful解决方案,但它似乎也会违反某些东西.RFC2046§1说:

Parameters are modifiers of the media subtype, and as such do not
fundamentally affect the nature of the content.  The set of
meaningful parameters depends on the media type and subtype.  Most
parameters are associated with a single specific subtype.  However, a
given top-level media type may define parameters which are applicable
to any subtype of that type.  Parameters may be required by their
defining media type or subtype or they may be optional.  MIME
implementations must also ignore any parameters whose names they do
not recognize.

请注意最后一句:

MIME implementations must also ignore any parameters whose names they do not recognize.

如果客户端识别出媒体类型的footnotes=true参数,这是否意味着客户端不符合要求text/plain？

Answer 1

在我看来,区别应该如下:

接受与响应打包有关的标头参数.

• 媒体类型(例如application/json)
• 字符编码(例如charset=utf-8)
• 结构(例如指定"doctype"的供应商扩展; application/vnd.example-com.foo+json; version=1.0)

查询参数与所处理的资源有关.

• 组件(例如标题和脚注)
• 可选功能(例如格式化)
• 约束(特别是在处理一系列类似的资源时)