【问题标题】:RESTfully request sub-parts of a representation be of a certain content-typeRESTfully 请求表示的子部分是某种内容类型
【发布时间】:2012-10-24 22:57:18
【问题描述】:

我正在请求(通过Accept: application/json)我正在设计的 API 以 JSON 响应。但是,我希望将 JSON 中的值指定为符合 text/plaintext/html,具体取决于客户端的功能。

“子类型”的 RESTful 最佳实践是什么?如果我正式切换到 HAL 作为顶级容器,这将如何工作?

接受:application/json+text/plain

{
  "value": "Hello World"
}

接受:application/json+text/html

{
  "value": "<h2>Hello World</h2>"
}

【问题讨论】:

  • "RESTful" 与这个问题无关。您只需使用您可以接受的类型指定 Accept: 标头。除非您知道服务器专门提供它们,否则我会很担心添加像 application/json+txt/html 这样的非标准后缀。任何高质量的 API 都应该清楚地记录可用的内容类型。
  • 完全正确,我可以简单地说 HTTP。我正在设计 API,并试图为客户找到最接近标准的做法,以便就该主题与服务进行通信。 application/json+txt/html 是我提出的几个非常尴尬的解决方案之一,但我认为它具有说明性。

标签: http rest content-type


【解决方案1】:

您是否考虑过在 Accept: 标头中使用参数?例如,请参阅如何为 JSON-LD http://json-ld.org/spec/latest/json-ld-syntax/#application-ld-json 定义配置文件参数。因此,例如,您的接受标头将是 application/json; profile="http://mysite.org/json-type/html"

还请记住,RFC 1341 中定义的 X 字段已弃用:https://www.rfc-editor.org/rfc/rfc6648

【讨论】:

  • +1 感谢您对x- 弃用的说明。我迟到了 5 个月的那部分!删除我的答案。
  • 这是我开始流行的更正式的版本。我已经尝试与 HAL 讨论列表进行一些异花授粉,以了解它是如何匹配的。我想避免混合使用 json-ld/HAL/json。 groups.google.com/d/msg/hal-discuss/HJAPsavOvPA/rPKv3-4yZyYJ
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-06-23
  • 1970-01-01
  • 1970-01-01
  • 2014-05-11
  • 1970-01-01
相关资源
最近更新 更多