java - Best practice for wrapping the body of ResponseEntity ajax style? -

with responseentity have direct control on http response; can set headers, body , http response code. , let's on client side have generic ajax data service expecting 3 response status conditions: success, fail, , error - status evaluated separately http status code, of course taken care of $.ajax. result, need generic object of sort body of responseentity, maybe below, data in jsonresponse whatever piece of data client requested; list of users, map of arbitrary data, (more on in second):

responseentityfactory.java

public class responseentityfactory {      private enum responsestatus {         success, fail, error     }      public static responseentity success (string message, object data) {         return getresponseentity(httpstatus.ok, responsestatus.success, message, data, null);     }      /* additional success, fail, error factory methods */      private static responseentity getresponseentity(httpstatus httpstatus, responsestatus responsestatus, string message, object data, httpheaders headers) {          if (httpstatus == null) throw new illegalargumentexception("httpstatus cannot null");         if (responsestatus == null) throw new illegalargumentexception("responsestatus cannot null");          jsonresponse jsonresponse = new jsonresponse(responsestatus, message, data);         return new responseentity(jsonresponse, headers, httpstatus);     }      private static class jsonresponse {          private responsestatus status;         private string message;         private object data;          public jsonresponse(responsestatus status, string message, object data) {             if (status == null) throw new illegalargumentexception("responsestatus cannot null");             this.status = status;             this.message = message;             this.data = data;         }          public responsestatus getstatus() {             return status;         }          public void setstatus(responsestatus status) {             this.status = status;         }          public string getmessage() {             return message;         }          public void setmessage(string message) {             this.message = message;         }          public object getdata() {             return data;         }          public void setdata(object data) {             this.data = data;         }      }  } 

examplecontroller.java

@controller @requestmapping(value = "/example") public class examplecontroller {      @autowire     private userservice userservice;              @requestmapping(method = requestmethod.get)     public responseentity getusers() {         list<user> users = userservice.getallusers();         return ajaxresponsefactory.success("found users", userlist);     }      @requestmapping(value = "/active/{id}" method = requestmethod.get)     public responseentity isuseractive(long userid) {         boolean = userservice.isuseractive(userid);         return ajaxresponsefactory.success(null, boolean);     } } 

the responseentityfactory simplifies controller, entire concern question centers around data variable (of type object) in jsonresponse - smells. testing i've done far, serializing correctly: single primitives, simple lists of string or long, more complex domain objects. question is, okay? there alternative? opportunity somehow use generics<t>?

again, main goal able evaluate http response code separately response status code of success, fail, error - in allows greater granularity when reacting server's response. instance, it's possible fail condition returned http 200 ok; http request successful, it'd inappropriate set otherwise, there validation error (maybe null username or something), disallowed action on server. argued these types scenarios technically of type 400 bad request, tend agree folks that, latest rfc 400 definition, these statuses should associated legitimate malformed requests, , not , arbitrary issue business logic.

so, what's best way ensure proper serialization of data object if i'd respond browser jsonresponse type object within responseentity? i'm open suggestions or alternatives - not tied @ all, seemed reasonable approach. i'd interested see if solving generics feasible and/or more desirable.