Jezz Santos - 287 - Mar 28, 2014

Can someone help with a gap in my understanding of REST design with ServiceStack?

Suppose I have any resource like users of a system. I have the standard methods:
GET /users - Lists all users
GET /users/{Id} - Get a specific user
POST /users - Creates a new user
PUT /users/{Id} - Updates a specific user
DELETE /users/{Id} - Deletes a specific user

The pattern above can be applied to almost any resource.
However, as a special case for UserAccounts, in addition to the above, I want retrieve a specific account by Username. Conceptually I want this:
GET /users/{Username}

However, the route is effectively the same as: GET /users/{Id}, and ServiceStack has no idea which one I really mean.

What is the basic design pattern for these kind of cases?

Wayne Brantley:

If your UserRequest object has a properties:
   int? Id {get;set;}
   string Username {get;set;}

Then your service just looks at the request object and figures out what to do.

Normally I would allow the Users collection to be filtered like:

GET /users?name={Name}

If I wanted a different url for it I would do something like:

GET /users/search?name=xxx

Otherwise if you want to use a different service that uses the path info, you could do something like:

GET /users/by-name/{Name}

Jezz Santos:

OK, cool thanks guys.

So in general, as a general pattern for any resource, I could just be looking at either: adding “search” (GET /users/search?field=value) or extending “list” (GET /users?field=value) or even both.


Wayne Douglas:

You can see the pattern we adopted here: with a question!

Wayne Brantley:

Yes or you could handle it with a single model and let the service figure out.   Looked at your question on stackoverflow…Looks fine to me…