提案

Question

因此，使用内容协商为同一资源获取不同的语言表示是很常见的：

GET /resource/12345 HTTP/1.1
Accept-Language: en-GB;q=9.0, fr;q=0.8, *
Accept: application/json

会以英国，法国或任何其他语言回馈。

{ "greeting": "Bon Jour" }

我认为这是正确的方法，到目前为止，我对内容协商的概念很满意。

不知何故，某个地方必须输入“Bon Jour”...现在，不知何故，使用REST，我想添加英国代表。

我很想介绍：

PUT /resource/12345 HTTP/1.1
Content-Language: en-GB
Content-Type: application/json

{ "greeting" : "Good Morning" }

人们可以选择性地删除翻译

DELETE /resource/12345 HTTP/1.1
Content-Language: pt_BR           # Portuguese Brasil

或删除整个资源而不指定Content-Language

然而

这些使用多语言版本资源的方法没有被描述。 RFC中没有任何内容。此外，Content-Language主要被视为响应标头，尽管旧RFC确实将其称为“实体”标头。

请在使用Content-Language标头字段指定HTTP方法应执行的特定语言时，对此建议发表评论。当然，GET没有内容正文，因此不需要指定内容语言。

什么是常见/最佳做法，尽可能避免在网址中添加语言？

Answer 1

基于内容语言以及其他内容协商功能，Web创作和处理资源的不同表示方式有多种方法。

然而，这从未被定义为可互操作，并且已从DeltaV标准中删除。

另一个讨论是围绕具有专门为修改资源元数据定义的PATCH主体格式。必须完成大量工作来定义格式以及如何表达应存在多少变体以及如何将内容信息分配给表示。

AFAICR重复讨论的要点是，为了通过HTTP进行Web创作并支持内容变体需要相当多的工作，而不仅仅是定义如何在PUT / DELETE上使用标头。创作客户需要一种方法来获取变体列表及其变化方式。

相比之下，正如您所看到的那样，Web服务器的各种实现都是从文件系统或数据库中提供文档，实现者已经提出了各种非HTTP方式的语言变体，一些更多，一些不那么RESTful在浏览器中获取语言变体的方式。文件系统通常不能支持没有大量上层结构的变体，内容协商似乎不是Web服务器或CMS服务器的顶级功能。

您可以尝试搜索IETF HTTP相关邮件列表的一些档案或发布到这些列表;那些人倾向于讨论这个问题的理论和架构方面，而不仅仅是担心本地实施权衡。