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.
thanks
Wayne Douglas:
You can see the pattern we adopted here: http://stackoverflow.com/questions/22708127/servicestack-conflicting-routes 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…