需要HTTP头的REST服务的推荐模式？

Question

我正在实现一个RESTful服务，它将由Dojo框架的RestStore使用，它将允许将服务绑定到各种小部件，如交互式网格或预先键入的ajax select。

RestStore希望发送和接收HTTP、Range和Content-Range报头，以便将查询结果限制在特定子范围内。

在ServiceStack (新的应用程序接口)中，将HTTP头作为服务的一部分进行响应的最佳实践模式是什么？通常，像Get这样的服务方法不能访问HTTP头，除非我错过了一个替代的API。

我目前看到的方法是实现一个属性，比如

 public class RangeSupporter : Attribute, IHasRequestFilter, IHasResponseFilter

它将在请求时解析报头，并在响应时写入报头。然后，将为此筛选器标记DTO。

过滤器将传入和传出DTO的值，比如'First‘和'Last’。然而，要知道DTO甚至有这样的属性，它必须有一些标记接口，比如

interface IHasRangeSupport {
    int First { set; get; }
    int Last { set; get; }
    int Total { set; get; }
}

以便筛选器可以使用类似以下代码的代码将信息传入和传出DTO：

  var r = request as IHasRangeSupport;
  if (r != null) {
      /// Access the DTO attributes for the range parameters
  }

这看起来像是一个很大的仪式，而且是一个非常笨拙的实现。

在实现REST服务时，有没有更好的访问HTTP头的模式？

在我的特定用例中，不需要支持非REST端点(如SOAP)。只有HTTP端点是重要的。

Answer 1

在ServiceStack (新的应用程序接口)中，将HTTP头作为服务的一部分进行响应的最佳实践模式是什么？

我相信你可以在你的服务类中获得头文件...

public class FooService : Service
{
    public object Get(Foo reqeust)
    {
       //get header
       var h1 = base.RequestContext.GetHeader("headerName");
       //get header differently
       var h2 = base.Request.Headers.Get("headerName");
    }
}