Thanks Paul. It works like a charm.
-Arul
Paul Sandoz wrote:
>
> On Nov 3, 2008, at 7:01 PM, Arul Dhesiaseelan wrote:
>
>> Thanks Paul.
>>
>> I assume in pattern 2 you meant PUT would return 201 (for add) and
>> PUT would return 200 (for update), right?
>>
>
> Yes.
>
>
>> Another design question: Does sub-resource locators really makes
>> sense in pattern 1, I see it is useful in pattern 2?
>>
>
> Yes, the POST is implemented on the class that has the sub-resource
> locator.
>
>
>
>> If I choose pattern 2 to implement my use case, I can use the below
>> approach in my parent resource, which helps me to chain resources:
>>
>> @Path("/root")
>> public class RootResource {
>> @Path("/users/{id}")
>> public UserResource getUserResource(@PathParam("id")long id) {
>> return new UserResource(uriInfo, request, root, id);
>> }
>> @Path("/roles/{id}")
>> public RoleResource getRoleResource(@PathParam("id")long id) {
>> return new RoleResource(uriInfo, request, root, id);
>> }
>> }
>>
>
>
> ... and implement PUT on the sub-resources.
>
>
>> I don't think it is possible to have sub-resource locators in pattern
>> 1? If this is the case, how can I chain the resources if I choose to
>> implement this pattern?
>>
>
> @Path("root") public class RootResource {
> // Create a sub-resource
> @POST public Response create() { ... }
>
> @Path("{id}")
> SubResource getSubResource(@PathParam("id") long id) { .... }
> }
>
> Paul.
>
>> Thanks again for the RESTful design tips.
>>
>> -Arul
>>
>> Paul Sandoz wrote:
>>> Hi Arul,
>>>
>>> There is no really need to have a GET request to return an id, it is
>>> redundant. There are then two very common patterns for creation of a
>>> new resource:
>>>
>>> 1) The server is in control of the URI space.
>>> The client sends a POST request and a 201 is returned with the
>>> URI that points to the newly created resource.
>>>
>>> 2) The client is in control of the URI space.
>>> The client sends a PUT request and a 201 is returned if the
>>> resource identified by the request UR is created
>>> otherwise a 200 is returned (assuming success).
>>>
>>>
>>> A example of 1) is:
>>>
>>> > POST /collection
>>>
>>> < 201 Created
>>> < Location: /collection/1234
>>>
>>>
>>> An example if 2) is:
>>>
>>> > PUT /collection/1234
>>>
>>> < 201 Created
>>> < Location: /collection/1234
>>>
>>>
>>> Ask the question: is the client or the server in control of the URI
>>> space for creation of the resource?
>>>
>>> For 1) there are also techniques for the client to hint to the
>>> server the URI might be (AtomPub uses a slug header).
>>>
>>> Paul.
>>>
>>> On Nov 3, 2008, at 5:38 PM, Arul Dhesiaseelan wrote:
>>>
>>>> Thanks Jeff and Paul for helping me out.
>>>>
>>>> May be I took a bad example to explain my use case. Let me try
>>>> again explaining my requirement again.
>>>>
>>>> In our system, we have set of JPA entities (users, roles, etc). We
>>>> have a Java API for end users to operate on these entities
>>>> (addUser, addRole, etc). But, we do not expose the "id" (primary
>>>> key) of these entities to the Java API. We are designing Rest API
>>>> to be used by web front end. Rest API would be using Java API to
>>>> operate on these entities (CRUD). Whenever, web users create "user"
>>>> entity, we invoke UserResource which in turn calls the Java API to
>>>> persist the user entity. The only unique piece of information for
>>>> this entity is "username".
>>>>
>>>> The first option I had in mind was to stub the "id" using an atomic
>>>> counter on the server-side (IdGenResource). These "ids" does not
>>>> match with the database "id" associated with the entity, but it is
>>>> just used to construct the unique URI.
>>>>
>>>> Request:
>>>> GET /id HTTP/1.1
>>>> Response:
>>>> HTTP 200 OK 1234
>>>>
>>>> Request:
>>>> POST /users/1234 HTTP/1.1
>>>> Content-type: xxx
>>>> Content-length: nnn
>>>>
>>>> ... etc ...
>>>>
>>>> Response:
>>>> HTTP 201 Created
>>>> Location: /users/1234
>>>>
>>>> I am not sure if this approach could be used to detect if a
>>>> resource was created then deleted as per Paul's suggestion. But,
>>>> this approach calls for an extra GET.
>>>>
>>>> Other option is to use the username as part of the URI:
>>>>
>>>> Request:
>>>>
>>>> POST /users/aruld HTTP/1.1
>>>> Content-type: xxx
>>>> Content-length: nnn
>>>>
>>>> ... etc ...
>>>>
>>>> Response:
>>>> HTTP 201 Created
>>>> Location: /users/aruld
>>>>
>>>>
>>>> Appreciate your inputs on the pros and cons of these approaches. Is
>>>> there any other better Restful approaches to be considered in
>>>> designing URIs?
>>>>
>>>> Thanks!
>>>> Arul
>>>>
>>>>
>>>> Paul Sandoz wrote:
>>>>>
>>>>> On Nov 1, 2008, at 4:18 AM, Jeff Schmidt wrote:
>>>>>
>>>>>> Hi Arul:
>>>>>>
>>>>>> I think you want to do this:
>>>>>>
>>>>>> @POST
>>>>>> @Consumes("application/xml")
>>>>>> @Produces("application/xml")
>>>>>> public Response addCustomer(Customer customer) {
>>>>>> long customerId = 1234L; //Wherever this comes from (DB
>>>>>> sequence, atomic counter etc.).
>>>>>
>>>>> If one utilizes an incremental counter then it is possible to
>>>>> detect if a resource was created then deleted and thus distinguish
>>>>> between 404 (Not Found) and 410 (Gone).
>>>>>
>>>>> An alternative is to use a UUID. Java has support for type 4 UUIDs
>>>>> (random ones) but this may result in collisions...
>>>>>
>>>>> Paul.
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>