使用 URI 与接受标头进行 REST 内容格式协商的优缺点是什么? [英] What are the Pros and Cons of using URI vs Accept Headers for REST content format negotiation?

问题描述

基于以下问题中的信息REST 内容类型:它应该基于扩展名还是接受标头?，我知道自定义 URI 或指定接受标头是 REST 式 Web 服务的可接受"(双关语)方法确定客户端的响应格式.

Based on info in the following question REST Content-Type: Should it be based on extension or Accept header?, I'm aware either custom URIs or specifying Accept Headers are 'acceptable' (pun intended) methods for for a REST-ish web service to determine response format for the client.

然而，很多大牌似乎在他们的 API 中使用自定义 URI 方法.一种方式相对于另一种方式的优势是什么?

However, a lot of big names seem to use the custom URI method with their APIs. What are the strengths of one way over the other?

推荐答案

在 REST 中，URI 仅用于标识资源.内容协商用于识别表示格式.这是您传统的关注点分离.当使用 URI 来识别表示格式时，您将这些问题混为一谈.

In REST, URIs are intended to identify only a resource. Content negotiation is used to identify representation format. It's your traditional separation of concerns. When using the URI to identify the representation format you are mixing those concerns.

除了混合问题之外，我的观察是，当使用基于 URI 的方法时，人们通常了解约定并依赖 URI 构建而不是超文本来导航.如果服务器想要更改 URI 结构，这会增加耦合并可能导致问题.

In addition to mixing concerns, my observation is that when using the URI based approach people generally know the convention and rely on URI building rather than hypertext to navigate. This increases coupling and can cause problems if the server ever wants to change the URI structure.

话虽如此，URI 方法有一些优点，即方便.在开发过程中，您可以启动浏览器，只需在地址栏 ('example.com/foo.json') 中输入即可轻松查看服务器响应的内容.当 100% 依赖于内容协商时，这有点困难，您必须依赖插件或 cURL，任何可以操纵标头的东西.

With that being said, there are some positives from the URI approach, namely convenience. During development, you can launch the browser and easily see what the server is responding with by simply entering it in the address bar ('example.com/foo.json'). When relying 100% on content negotiation it's a bit more difficult, and you have to rely on plugins or cURL, anything that can manipulate the headers.

这篇关于使用 URI 与接受标头进行 REST 内容格式协商的优缺点是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！