Filter attributes

ServiceStack also contains interfaces for attributes which can be executed before and after a request like request/response filters. The filter attributes make a great job when the services get bloated more and more, because you can put the new functionality probably into a filter attribute and as result the services stay clean. You can also reuse your custom filter attributes, which is another great advantage, because there would be no duplicate code in the service implementations.

For example, ServiceStack internally uses filter attributes for Authenticate and RequiredPermission to mark that the specific service needs authentication or a specific permission (see Authentication and authorization).

There are two interfaces which you have to implement in your custom attribute:

If you implement this interface, the method RequestFilter will be executed before the service gets called.

    public interface IHasRequestFilter {
        void RequestFilter(IHttpRequest req, IHttpResponse res, object requestDto);
        int Priority { get; }      // <0 Run before global filters. >=0 Run after
        IHasRequestFilter Copy();  // Optimization: fast creation of new instances
    }

If you implement this interface, the method ResponseFilter will be executed after the service was called.

    public interface IHasResponseFilter {
        void ResponseFilter(IHttpRequest req, IHttpResponse res, object responseDto);
        int Priority { get; }      // <0 Run before global filters. >=0 Run after
        IHasResponseFilter Copy();  // Optimization: fast creation of new instances
    }

---

It's recommended that you create separate attributes for each interface, but of course you can implement both interfaces in one attribute, too.

    public class RequestFilterAttribute : Attribute, IHasRequestFilter {
        public void RequestFilter(IHttpRequest req, IHttpResponse res, object requestDto)
        {
            //This code is executed before the service
            string userAgent = req.UserAgent;
            StatisticManager.SaveUserAgent(userAgent);
        }
    }

    public class ResponseFilterAttribute : Attribute, IHasResponseFilter {
        public void ResponseFilter(IHttpRequest req, IHttpResponse res, object responseDto)
        {
            //This code is executed after the service
            res.AddHeader("Cache-Control", "max-age=3600");
        }
    }

As you can see, you can access the IHttpRequest, IHttpResponse and the request/response DTO. So you can change the DTO, the http response (eg status code) or look for a specific header in the http request. You can also attach any data to this request via the IHttpRequest.Items dictionary that all subsequent filters and services can access.

---

These two attributes have to be added to a request/response DTO or to the service implementation to enable them.

    //Request DTO
    [Route("/aspect")]
    [RequestFilter]
    public class User
    {
        public string Name { get; set; }
        public string Company { get; set; }
        public int Age { get; set; }
        public int Count { get; set; }
    }
    
    //Response DTO
    [ResponseFilter]
    public class UserResponse : IHasResponseStatus
    {
        public string Car { get; set; }
        public ResponseStatus ResponseStatus { get; set; }
    }

...or if you don't want the code-first DTOs messed with attributes:

    [RequestFilter]
    [ResponseFilter]
    public class AspectService : Service
    {
        public object Get(Aspect request)
        {
            ...
        }
    }

That's all, now ServiceStack recognizes the attributes and executes them on every call!

---

For filter attributes auto-wiring is also supported (like in services and validators):

    public class RequestFilterAttribute : Attribute, IHasRequestFilter
    {
        //This property will be resolved by the IoC container
        public ICacheClient Cache { get; set; }
        
        public void RequestFilter(IHttpRequest req, IHttpResponse res, object requestDto)
        {
            //Access the property 'Cache' here
            
            //This code is executed before the service
            string userAgent = req.UserAgent;
            StatisticManager.SaveUserAgent(userAgent);
        }
    }

In this case the property Cache will be tried to be resolved by the IoC container.

---

ServiceStack also has two base classes, which implement the above interfaces, which make it easier to create contextual filters. Contextual filters are only executed on specific HTTP verbs (GET, POST...).

    public class StatisticFilterAttribute : RequestFilterAttribute
    {
        //This property will be resolved by the IoC container
        public ICacheClient Cache { get; set; }
        
        public StatisticFilterAttribute()
        {
        }

        public StatisticFilterAttribute(ApplyTo applyTo)
            : base(applyTo)
        {
        }

        public override void Execute(IHttpRequest req, IHttpResponse res, object requestDto)
        {
            //This code is executed before the service
            string userAgent = req.UserAgent;
            StatisticManager.SaveUserAgent(userAgent);
        }
    }

The base class RequestFilterAttribute has an empty constructor and a constructor which takes the ApplyTo flag. If the empty constructor is called, the method Execute will be called on every HTTP verb (ApplyTo.All), with the other constructor it will be called only on the configured HTTP verbs (eg ApplyTo.Get | ApplyTo.Post).

So you can use the attribute on your request DTO/service like that:

//Filter will be executed on every request
[StatisticFilter]
...

//Filter will be executed only on GET and POST requests
[StatisticFilter(ApplyTo.Get | ApplyTo.Post)]
...

For response filters, there's the base class ResponseFilterAttribute which works the same as RequestFilterAttribute.