使用`Expect` HTTP标头来表示有关HTTP响应状态代码的首选项

时间:2014-03-20 17:50:31

标签: api http rest restful-architecture

我正在尝试找到符合标准(或符合良好做法)的方式,告知RESTful API服务器API客户端更喜欢特定代码,但可以在必要时处理其他代码。

即,例如,在创建一个POST调用/items网址的资源时,您可以:

  1. 接收包含新创建资源的表示的201 CREATED响应,
  2. 如果创建需要等待的时间超过服务器希望花费在生成和返回响应上的时间(例如,因为某些内容是异步完成的),则接收202 ACCEPTED响应,
  3. 接收204 NO CONTENT响应,空体和一些Location标题指向资源的位置,
  4. 关键是让服务器知道,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 ...)。

2 个答案:

答案 0 :(得分:1)

我会使用查询参数给服务器提示。也许像?body=false&wait=5000这样的东西。 wait,尤其不是理想的,因为它可以通过缓存进行操作 - 您可以使用不同的等待时间为相同的响应获取多个缓存条目。更常见的是body(或者相当于等同名称)。

另一种选择是使用自定义标头,但是您必须注意可能剥离它们的任何中间服务器(代理,负载平衡器,中间缓存)。

您是否考虑过将等待时间设为用户或应用程序级首选项?

答案 1 :(得分:1)

期望不适用于此,但“首选”标题字段可能是您正在寻找的。请参阅http://tools.ietf.org/html/draft-snell-http-prefer-18