前言:
在阅读了很多关于HTTP和REST的内容之后,您花了几个小时来设计一个狡猾的内容协商方案.这样您的Web API就可以从单个URL提供XML,JSON和HTML.因为,您知道,资源应该只有一个URL,并且应该使用Accept标头请求不同的表示.你开始想知道为什么它花了20年的时间来实现这个目标.
那就是现实让你黯然失色.
因此,为了帮助浏览器(以及您自己尝试调试)强制您的服务来提供所需的内容类型,您可以做每个自尊的REST传播者会鄙视您的内容:文件扩展名.
在地狱中永恒的折磨,是以下使用Content-Location+ .ext接受？
假设我们有用户在/users/:loginname例如/users/bob.这将是任何能够设置正确Accept标头的API端点.但对于任何可能的Content-Type(或至少一些),我们允许另一种访问方法,即具有文件类型后缀的URL.例如/users/bob.html,对于HTML表示.让我们假设(这是一个很大的假设)登录名永远不会包含句点/点.
请求:
GET /users/bob.json HTTP/1.1
Host: example.com
响应:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 14
Content-Location: /users/bob
{"foo": "bar"}
这将允许我编码访问(在这种情况下)用户信息的替代方法.例如,可以是指向用户页面的链接<a href="/users/bob.html">Bob</a>.指向vCard的链接(将用户添加到地址簿/ Outlook /任何内容)将是<a href="/users/bob.vcf">Bob</a>.
我错过了任何陷阱吗？这有什么优点/缺点？
编辑:这有点迟了让我注意到.即使它涉及到主题并且真的很有帮助,我认为这并不是我正在寻找的......