我正在尝试找到符合标准(或符合良好做法)的方式,告知RESTful API服务器API客户端更喜欢特定代码,但可以在必要时处理其他代码。
即,例如,在创建一个POST
调用/items
网址的资源时,您可以:
201 CREATED
响应,202 ACCEPTED
响应,204 NO CONTENT
响应,空体和一些Location
标题指向资源的位置,关键是让服务器知道,API客户端更喜欢201 CREATED
在响应正文中使用资源表示,但也会接受任何其他响应。出于性能原因(为了避免从服务器获取实际资源的单独调用)和向后兼容性(可能假设服务器总是返回204 NO CONTENT
的API客户端,并且他们需要从服务器获取资源,将会发出优先级信号时间。
如何表达偏好,不会导致收到回复失败?官方规范(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.20)似乎没有解决这个问题:
14.20期待
Expect request-header字段用于表示该特定字段 客户端需要服务器行为。
Expect = "Expect" ":" 1#expectation expectation = "100-continue" | expectation-extension expectation-extension = token [ "=" ( token | quoted-string ) *expect-params ] expect-params = ";" token [ "=" ( token | quoted-string ) ]
不理解或无法遵守任何规定的服务器 请求的Expect字段中的期望值必须响应 具有适当的错误状态。服务器必须以417响应 (期望失败)状态,如果无法满足任何期望 或者,如果请求有其他问题,其他一些4xx 状态。
此头字段使用可扩展语法定义以允许 未来的扩展。如果服务器收到包含Expect的请求 包含不支持的期望扩展的字段, 它必须以417(期望失败)状态作出回应。
期望值的比较对于不带引号的情况不区分大小写 令牌(包括100-continue令牌),并且区分大小写 quoted-string expectation-extensions。
Expect机制是逐跳的:即HTTP / 1.1代理必须 如果收到请求,则返回417(期望失败)状态 期望它无法满足。但是,Expect请求标头 本身是端到端的;如果请求必须转发它 转发。
许多旧的HTTP / 1.0和HTTP / 1.1应用程序都不理解 期待标题。
有关使用100(继续)状态的信息,请参阅8.2.3部分。
当然有例如。 API版本控制或自定义内容类型(包含版本信息)的替代方案。但第一个是麻烦(太多版本不能立即支持,而不是单个支持非常灵活),第二个似乎是错误的(自定义内容类型,而你总是提交例如.XML?nah ...)。
答案 0 :(得分:1)
我会使用查询参数给服务器提示。也许像?body=false&wait=5000
这样的东西。 wait
,尤其不是理想的,因为它可以通过缓存进行操作 - 您可以使用不同的等待时间为相同的响应获取多个缓存条目。更常见的是body
(或者相当于等同名称)。
另一种选择是使用自定义标头,但是您必须注意可能剥离它们的任何中间服务器(代理,负载平衡器,中间缓存)。
您是否考虑过将等待时间设为用户或应用程序级首选项?
答案 1 :(得分:1)
期望不适用于此,但“首选”标题字段可能是您正在寻找的。请参阅http://tools.ietf.org/html/draft-snell-http-prefer-18。