Nick Karnik - 219 - Oct 12, 2014

Is it possible to define routes on the Service methods directly instead of a Request DTO? Sometimes I have simple things like “/api/locations” and don’t need a Request DTO.

Something like 
[Route("/locations")]
        public IEnumerable<Location> Get()
        {
return …
        }

Although, the above doesn’t work for me. So, I was wondering what else I could do to avoid creating a request DTO. Thanks!

No. This is against the core design in ServiceStack, every Service is identified by a uniquely named Request DTO which defines the Services external facing Service Contract, used by the metadata services, typed service clients, what behavior gets attached to, etc.

Just use an empty DTO:

[Route("/locations")]
public class GetLocations {}

Nick Karnik:

Thanks, make sense. It does seem counter productive when there are 50 empty classes to support static routes without parameters.

Do you really have 50 static routes? Can they be combined into more coarse-grained cohesive services? Are these routes for HTML pages? in which case you don’t need a service at all and can call the Razor pages directly and retain a pretty route, see: http://razor.servicestack.net/#no-ceremony

Nick Karnik:

These routes are strictly API only.

Think about a location table. A LocationRequest DTO can handle the basic CRUD operations which means GET maps to something like GetLocationById.

Now, when I need to support GetAllLocations, I cannot use the same DTO as the GET route is already mapped to GetLocationById. So, I end up with another DTO called AllLocationsRequest which maps to GetAllLocations.

An alternative is to do some route lookups in the service method, but that starts to get messy sometimes. The separate DTO’s keeps it clean.

Another alternative is to use URL parameters to do the filtering, so essentially the GET route could be ‘/api/locations’ and using url params we could look for something like ID=1. Again, that requires us to check for several conditions to see which parameters are passed in.

The separate DTO route keeps it very simple.

Is there a recommended way of handling these operations using the Location table above as an example? Thanks.

Here’s some info on desigining more coarse-grained API’s: 
http://stackoverflow.com/a/15941229/85785
In this case I would have a single Service called Find or ‘SearchLocations’ where every parameter filters the result set, and no filters returns all locations. You may also be able to use AutoQuery and avoid having to write the Service impl at all: https://github.com/ServiceStack/ServiceStack/wiki/Auto-Query

Sir Thomas:

In the same boat actually - our request DTO count is quite high, and never seem to have the time to find a better way to consolidate.

Nick Karnik:

Thanks for the design tips!