Duplicate servicestack endpoints or extend existing one for similar functionality?

Question

We implemented different endpoints with serviceStack. We often face a debate in the team whether to extend an existing endpoint or rather to create a new DTO object when a similar functionality already exists.

As example, to provide a generic user search functionality, we have the following DTO User and a GET endpoint:

public class UserDto
{
    public long Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string NickName { get; set; }
    public DateTime? DateOfBirth { get; set; }
    public long CountryOfBirth { get; set; }
}


[Route("/Users/search", "GET")]
public class SearchUser : PagedRequest,IReturn<PagedResult<UserDto>>
{
    public string Query { get; set; }
}

The implementation of the GET endpoint searches over the database for potential matches against the provided query parameter and returns paged UserDto results with full fields.

Let's consider the search should be executed also from a different area of the application, with different permissions and showing only a subset of UserDto fields (only first and last name).

Would it be better to extend the current endpoint logic, trying to establish from where the endpoint is called and removing the unnecessary fields before returning or would it be preferable to create a new dedicated endpoint? That is, being more redundant, but keeping the implementation more simple?

score 3 · Accepted Answer · edited May 23 '17 at 12:31

My guide on whether to group Services or not is to group them by Call Semantics and Response Type where as long as adding new functionality of a Service doesn't change existing behavior or change the meaning of a Service (e.g. each property on a Search Service acts like a filter) then I'd look to add them on a existing Service.

Since it sounds like you want to change the Response Type for the new Service I would create a new Service with the explicit response type of what it returns.

Where possible I'd still look at maximizing re-use where possible, e.g. if this new Service just filtered the Response I would call the existing Service from the new one and map the results using a custom extension method, e.g:

public class MyServices : Service
{
    public object Any(SearchUserAuthenticated request)
    {
        var response = Any(request.ConvertTo<SearchUser>());
        var userSession = base.SessionAs<AuthUserSession>();
        return new SearchUserAuthenticated {
            Results = response.Results.Map(x => x.ToDto(userSession))
        };
    }

    public object Any(SearchUser request) { ... }
}

Thanks mythz for the link to the excellent explanation. In my case, the new search would have almost the exact business logic of the existing code. The doubts were whether to create a new DTO as subset of the existing UserDTO or reuse the current one, without having all the properties mapped. I will reuse the existing endpoint, adding a new custom extension to return only a subset of properties to the client. — Francesco, Jul 03 '15 at 06:42

Duplicate servicestack endpoints or extend existing one for similar functionality?

1 Answers1