2

I am just getting into REST and ServiceStack and for now my GETs are returning strings which could be XML or Json.

I now need to work on the PUT or POST commands which change my domain model.

For a single resource, I could have a number of commands on my domain model (i.e for a customer resource I could have change name, change address, change billing address, etc). Each change to the domain model will consist of only one of these changes (not all).

With ServiceStack do I create ONE DTO which contains a flag/enumeration to indicate what the change is? This means I have one REST service with a case statement to indicate what I should do on the domain. This also means I have a very large DTO object which contains the data that needs to be posted to change my domain (of which a lot of the properties will be empty).

Or do I create lots of DTOs and REST services, each specific to the change on my model? In this case would I need to add ?Command=changeAddress to the URL? Not sure if this is right.

JD.
  • 15,171
  • 21
  • 86
  • 159

1 Answers1

4

This also means I have a very large DTO object which contains the data that needs to be posted to change my domain (of which a lot of the properties will be empty).

A very large DTO object with empty properties is not a performance issue since ServiceStack's text serializers (i.e. JSON/JSV) only emit data for non-null values and doesn't spend time de-serializing what's not in the payload - so it shouldn't be a concern from a performance perspective.

Other than requiring the same Request DTO to be used for each of your REST Service Verbs - there is no "ServiceStack way" on how to design your services and ServiceStack doesn't force a design-style.

If you want to prefer a more REST-ful design, you would split up your customer into manageable entities that can be modified separately, e.g to change a customers Billing address I would do something like:

PUT /customers/address/billing
{
    "Line1": "123 Street",
    "City": "Brooklyn",
    "State": "NY"
}

And have a separate REST service to manage customer addresses, e.g:

Register<CustomerAddress>("/customers/address/{AddressType}");
mythz
  • 141,670
  • 29
  • 246
  • 390
  • In the example above, if I was going to change the shipping address and not the billing address, would it not be the same service? In other words how do I distinguish between billing and shipping changes? Or would I have Register<>("customer/address/shipping") and Register("customer/address/billing")? – JD. Apr 12 '12 at 05:36
  • The same CustomerAddress service. The AddressType property will get populated with the type which you can use to distinguish between them. – mythz Apr 12 '12 at 05:39
  • Thanks. So you are saying in this case, one service but two paths to manage the "billing" and "shipping" address? If this is right, would it make sense for two separate services, one for billing and one for shipping? – JD. Apr 12 '12 at 14:04
  • If it's the same entity I would only have 1 service handling different addresses. AddressType is just another property in the CustomerAddress DTO. – mythz Apr 12 '12 at 14:48