I might be misunderstanding what you're trying to do / concerned about, but
your get methods for each POJO can / should be annotated in the POJO, and
you would then use "sub-resources" or navigation methods in your root
resource. Something like
root resource------------------------
@Path("base")
public class RootResource {
@Path("mypojo/{id}")
public MyPojo findOnePojo(// inject id
return findMyPojoByPK(id);
}
}
pojo ------------------------------------
public class MyPojo {
@Path("")
@GET
@Produces(MediaType.APPLICATION_XML)
public MyPojo doGetWhole() {
return this;
}
@Path("feature")
@GET
@Produces...
public Xxxx getFeature() {
return this.feature;
}
}
HTH
Simon
From: Richard Sand <rsand_at_idfconnect.com>
> To: "users_at_jersey.java.net" <users_at_jersey.java.net>
> Cc:
> Date: Wed, 07 Aug 2013 13:55:51 -0400
> Subject: [Jersey] question about simple pojo pattern with uri parameters
> Hi all - quick question about the best way to create a single resource for
> supporting CRUD operations on several different POJOs.
>
> I have two POJOs which represent two tables in a database. Each POJO has
> getters and setters for the fields in each table. Each has an "ID" field
> which is a number for the primary key.
>
> I have a resource class which initializes the database connections and
> controls the POJOs. All of the operations take the ID field on the URI. So
> a request for:
>
> GET /admin/pojo1/12345
>
> will return POJO1 with id=12345 as a JSon object - this works fine. My
> Admin class has a method called getPojo1 with @Path("pojo1/{id: [0-9]*}")
>
> Now I want to support manipulating individual fields as Strings, like:
>
> GET /admin/pojo1/12345/field1
> PUT /admin/pojo1/12345/field1/**newvalue
>
> Right now, this means adding methods for each individual field for each
> POJO into my Admin class. So my simple question is - is there better
> dispatch pattern I can use in my Admin class that doesn't require a
> separate method for each POJO x Field x Method? 5 POJOs times 15 fields per
> POJO times 4 methods = 300 methods = ugly!
>
> Thanks for any advice!
>
> Best regards,
>
> Richard
>
>
>