java - Returned JSON object does not respect inheritance? -

i have google cloud endpoint api returns product object. product object contains object brand large (id, name, text, description, image urls, ...). when getting list of products don't need whole information inside brand, id , title.

so tried factor out brand base class brandbase contains limited set of properties (only id , title). , inside product in public brandbase getbrand() method return brandbase object.

but looking @ json output google cloud endpoints - still whole brand content (including text, description, etc). looks google cloud endpoint looks @ object-type , serializes regardless of specified return type in class itself?

@entity public class product {   @id   private long id;    @index   private ref<brandbase> brand;    public brandbase getbrand() {     return brand.get();   }    public void setbrand(brandbase brand) {     this.brand = ref.create(brand);   }   ... }  @entity public class brand extends brandbase {    @id   private long id;   @index   private string name;   private string text;   private string contact;   ... getter/setter ... }  public abstract class brandbase {   public abstract long getid();   public abstract string getname();   public abstract void setname(string name); } 

the returned json is:

{    "id": "6298002603900928",    "title": "magna aliquyam erat, sed",    "description": "lorem ipsum dolor sit amet...",    "brand": {      "id": "6192449487634432",      "name": "no",      "text": "lorem ipsum dolor sit amet, ...",      "contact": "lorem ipsum dolor..."    }  } 

so still contains text , contact - both not specified in brandbase class.

is bug or feature of google cloud endpoints? or there other methods desired behavior: want have shallow brand object inside product - not full brand object.

this not bug in endpoints, otherwise there no way return polymorphic objects. furthermore, every json serializer in existence works same way.

i not expert in cloud endpoints, run across architectural problem , solve in same way:

you need separate data model api model. passing entity objects , forth works simple entity objects , simple applications. when need different views of objects different callers, or hide pieces of data, it's time think separate dtos.

for clients hard upgrade (like native apps deployed in field), should start dtos immediately. gives freedom refactor data model see fit while controlling api compatibility. yes, it's more work, save major headaches down road. use http://projectlombok.org/ rid of of boilerplate.