views:

41

answers:

2

Hi, I'm trying to figure out how to best lay out a set of Restlet APIs. I have a User entity, which might have the standard CRUD operations, which fits nicely into rest, but there are other ones too like "reset password", or "terminate".

What is the best way to lay this out?

Here is what i was thinking:

/1.0/user/update        //perhaps this would just be a PUT on /1.0/user
/1.0/user/resetPassword //This would reset the password, but also send an email.
/1.0/user/terminate     //This might do some additional cleanup

Then I would make a UserResource that would really attach like this

/1.0/user/{actionType}

And the handling code might look like this (psuedo):

action = request.getAttributes().get("actionType");
if (action == "update") {
   do update
} elif (action == "resetpassword") {
   do resetpassword
} elif (action == "terminate") {
   do terminate
}

Really bad idea? Really ninja idea?

+1  A: 

I think it's an OK idea. If you want your application to be RESTful, you really have to provide links in the representation for your User resource, and document them as URIs that perform the selected actions.

The Sun Cloud API does just this:

  • GET a VM returns a representation VM including "controllers" that are URIs that perform functions (see description of the VM media type)
  • Client knows about the media type, recognizes controllers (e.g. a VM provides "start", "stop" etc.
  • URI of control resource for that particular VM is right there

So as you can see, if you use /1.0/user/resetPassword or /1.0/user?op=resetPassword or /1.0/resetPassword?userId=xyzzy is a bit irrelevant, since the client really shouldn't care, it merely follows links in representations.

Also, remember to use POST for such operations since they are generally not idempotent and they probably have side effects.

mogsie
A: 

How about these?

PUT /user/bob 
DELETE /user/bob/password 
DELETE /user/bob 

and don't forget mogsie's point that the client should discover these URLs from some other document, it should not know them in advance.

Darrel Miller
I wouldn't say that it is so obvious to DELETE one's password in order to get a new one, if that's what it implied. But it could be a nice, idempotent thing if each password were its own resource, re-deleting it would have no effect, since deletion of one password would generate a new password resource at a different URI. Interesting idea.
mogsie