On 25/01/13 16:18, Christian Schneider wrote:
On 25.01.2013 17:11, Sergey Beryozkin wrote:
Hi Christian
On 25/01/13 15:56, Christian Schneider wrote:
When doing the CXF version of the UserRequestService I found that our
current UserRequestController does not really follow the rest ideas.
The problem is that it does follow the idea of doing CRUD operations on
resources. Some methods work with userId others with requestId. So for
example the are create, update and delete operations but they
do not mean the UserRequest but the underlying user.
So I worked out a new interface that purely works on UserRequest and
only supports POST, READ and DELETE. So basically if you want to create
or delete or update a user you will POST a UserRequestTO in all cases.
I added constructors to the UserRequestTO to make the use cases simpler.
request to create a user: userRequestService.create(new
UserRequestTO(userTO));
request to update a user: userRequestService.create(new
UserRequestTO(userMod));
request to delete a user: userRequestService.create(new
UserRequestTO(userTO.getId()));
So what do you think about this?
IMHO it would be nicer to avoid overloading proxy "create" request to
mean different things, definitely would not use "create" to mean
"delete" - perhaps it is a typo, the interface below suggests it might
be ? Would also use "update()" for updates
Just my 2c :-)
Honestly I was confused by the old interface in the same way.
Basically the idea is that the UserRequestService handles UserRequest
resources. A UserRequest is a request to do something on a user it is
not directly an operation on a user. So I used create in the meaning to
create a new UserRequest like you would create a workflow instance. Of
course the meaning of this request can be to delete a user at a later
point but we are still creating a UserRequest at this point. So I think
a POST of a new UserRequest is the right thing to do.
Sure, whatever makes sense from the flow perspective is better be
supported well at the API level, agreed, it is just that we have
"create" overloaded, we can have different proxy methods mapped to
different URI patterns, example, update() -> @POST @Path(/users/update),
create() -> @POST @Path(/users/create), would still be @POST but
different function names at the API level
Cheers, Sergey
Christian
