Tweeted twitter.com/StackSoftEng/status/852764610272702464
2 edited to add more context
source | link

I had a discussion about standardizing return structures in an API and the best way to enforce it across our services. The quickest way we went with was just to have our controllers in .NET Web Api return the same templated class so we came up with something like this

class ResponseObject<T> 
{
    public T Data {get;set;}
    public stringPermissions SomePropertyUserPermissions {get;set;}
    public stringMessage SomeOtherPropertyObjectMessage {get;set;}
    public Status ObjectStatus {get;set;}
}

And each controller returns this strcuture and fills in the common properties. We also made some helper functions so that controllers that shared the same return type T weren't rewriting the same things over and over.

This works OK for the most part but my idea was instead of every controller doing this, to turn it into an action filter.

public class MyResponseHandler : ActionFilterAttribute
{
    public override OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
    {
        var objectContext = actionExecutedContext.Response.Content as ObjectContent;
        if(objectContent != null)
        {
            var val = objectContent.Value;
            var type = objectContent.ObjectType;

            actionExecutedContext.Response = actionExecutedContext.Request.CreateResponse(actionExecutedContext.Response.StatusCode, 
                                                                                          new ResponseObject<type>(){data = val})
        }
    }
}

For the other properties in the common ResponseObject my idea was that these could also be handled with more action filters in the pipeline to fill them in. I thought this was a good approach because the developers would only have to worry about returning the object they really cared about for the controller and then the pipeline would handle everything the same way for each type of object. In the end we deemed it overkill and there was some concern that the pipeline would have too much logic and decisions made in it leading to a bunch of hard to debug errors. But I'm curious to see what other people thought of this approach or if anyone has done anything similar to enforce return structures in an API.

I had a discussion about standardizing return structures in an API and the best way to enforce it across our services. The quickest way we went with was just to have our controllers in .NET Web Api return the same templated class so we came up with something like this

class ResponseObject<T> 
{
    public T Data {get;set;}
    public string SomeProperty {get;set;}
    public string SomeOtherProperty {get;set;}
}

And each controller returns this strcuture and fills in the common properties. We also made some helper functions so that controllers that shared the same return type T weren't rewriting the same things over and over.

This works OK for the most part but my idea was instead of every controller doing this, to turn it into an action filter.

public class MyResponseHandler : ActionFilterAttribute
{
    public override OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
    {
        var objectContext = actionExecutedContext.Response.Content as ObjectContent;
        if(objectContent != null)
        {
            var val = objectContent.Value;
            var type = objectContent.ObjectType;

            actionExecutedContext.Response = actionExecutedContext.Request.CreateResponse(actionExecutedContext.Response.StatusCode, 
                                                                                          new ResponseObject<type>(){data = val})
        }
    }
}

For the other properties in the common ResponseObject my idea was that these could also be handled with more action filters in the pipeline to fill them in. I thought this was a good approach because the developers would only have to worry about returning the object they really cared about for the controller and then the pipeline would handle everything the same way for each type of object. In the end we deemed it overkill and there was some concern that the pipeline would have too much logic and decisions made in it leading to a bunch of hard to debug errors. But I'm curious to see what other people thought of this approach or if anyone has done anything similar to enforce return structures in an API.

I had a discussion about standardizing return structures in an API and the best way to enforce it across our services. The quickest way we went with was just to have our controllers in .NET Web Api return the same templated class so we came up with something like this

class ResponseObject<T> 
{
    public T Data {get;set;}
    public Permissions UserPermissions {get;set;}
    public Message ObjectMessage {get;set;}
    public Status ObjectStatus {get;set;}
}

And each controller returns this strcuture and fills in the common properties. We also made some helper functions so that controllers that shared the same return type T weren't rewriting the same things over and over.

This works OK for the most part but my idea was instead of every controller doing this, to turn it into an action filter.

public class MyResponseHandler : ActionFilterAttribute
{
    public override OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
    {
        var objectContext = actionExecutedContext.Response.Content as ObjectContent;
        if(objectContent != null)
        {
            var val = objectContent.Value;
            var type = objectContent.ObjectType;

            actionExecutedContext.Response = actionExecutedContext.Request.CreateResponse(actionExecutedContext.Response.StatusCode, 
                                                                                          new ResponseObject<type>(){data = val})
        }
    }
}

For the other properties in the common ResponseObject my idea was that these could also be handled with more action filters in the pipeline to fill them in. I thought this was a good approach because the developers would only have to worry about returning the object they really cared about for the controller and then the pipeline would handle everything the same way for each type of object. In the end we deemed it overkill and there was some concern that the pipeline would have too much logic and decisions made in it leading to a bunch of hard to debug errors. But I'm curious to see what other people thought of this approach or if anyone has done anything similar to enforce return structures in an API.

1
source | link

Using Web Api pipeline to standardize return structures

I had a discussion about standardizing return structures in an API and the best way to enforce it across our services. The quickest way we went with was just to have our controllers in .NET Web Api return the same templated class so we came up with something like this

class ResponseObject<T> 
{
    public T Data {get;set;}
    public string SomeProperty {get;set;}
    public string SomeOtherProperty {get;set;}
}

And each controller returns this strcuture and fills in the common properties. We also made some helper functions so that controllers that shared the same return type T weren't rewriting the same things over and over.

This works OK for the most part but my idea was instead of every controller doing this, to turn it into an action filter.

public class MyResponseHandler : ActionFilterAttribute
{
    public override OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
    {
        var objectContext = actionExecutedContext.Response.Content as ObjectContent;
        if(objectContent != null)
        {
            var val = objectContent.Value;
            var type = objectContent.ObjectType;

            actionExecutedContext.Response = actionExecutedContext.Request.CreateResponse(actionExecutedContext.Response.StatusCode, 
                                                                                          new ResponseObject<type>(){data = val})
        }
    }
}

For the other properties in the common ResponseObject my idea was that these could also be handled with more action filters in the pipeline to fill them in. I thought this was a good approach because the developers would only have to worry about returning the object they really cared about for the controller and then the pipeline would handle everything the same way for each type of object. In the end we deemed it overkill and there was some concern that the pipeline would have too much logic and decisions made in it leading to a bunch of hard to debug errors. But I'm curious to see what other people thought of this approach or if anyone has done anything similar to enforce return structures in an API.