On Feb 1, 2011, at 12:59 PM, Paul Sandoz wrote:
>
> On Feb 1, 2011, at 11:07 AM, Markus Karg wrote:
>
>> We currently have the following code, which is prototypical for a
>> POST / GET combination. POST is implemented by the root resource,
>> and must return a location header pointing to the created sub
>> resource. Then, a client can use that URI to GET a sub resource,
>> implemented by a second class:
>>
>> @Path("myroot") public class RootResource {
>> @POST public post() {
>> …create in database and request id from it…
>> URI location = UriBuilder.fromResource(SubResource.class).build(…
>> id from database…);
In my haste i did not see the above. You definitely don't want to
declare SubResource as a root resource.
UriInfo ui = ...
Method m = ...
ui.getRequestUriBuilder().path(m).build(…id from database…);
it ain't ideal because it is a PITA to reference methods in Java.
Otherwise declare the "{id}" as a string constant and refer to that in
the builder and the @Path annotation on getSubResource method:
UriBuilder.fromPath(ID_PATH).build(…id from database…);
Paul.
>> return Response.created(location).build();
>> }
>> @Path("{id}") public SubResource getSubResource() {
>> return new SubResource();
>> }
>> }
>>
>> @Path("{id}") public class SubResource {
>> @GET public String get() {
>> return … ;
>> }
>> }
>>
>> That works pretty well, but it is not smart that @Path is needed at
>> both, the getSubResource() method AND the SubResource class.
>>
>> I wonder if we can get rid of one of those, as the information
>> provided by both actually is the same.
>>
>
> Is it intended that SubResource also be a root resource? i.e. /
> myroot and /{id} are valid paths, in addition to /myroot/{id}
>
> If not you don't need @Path on SubResource.
>
> Paul.