Take the 2-minute tour ×

Is there a reason why I need to supply IReturn or IReturnVoid references to ServiceStack's JsonServiceClient.Get? There must be a good reason (I'm quite new to the framework) but I don't understand why I have to convert my objects to IReturn wrappers or make them ServiceStack dependant.

I have read those posts but couldn't find the explaination I am looking for (only workarounds):


share|improve this question
It just lets you add metadata on your Request DTO's that are accessible in your .NET clients so it can enable a more terse client API. See the C# Client wiki for examples with and without the IReturn markers. The inspiration for the IReturn markers came from Ivan Korneliuk's proposal for a cleaner client API –  mythz Sep 15 '13 at 3:44
add comment

1 Answer

up vote 4 down vote accepted

JSON is an untyped data format. Well, there are string and numeric, arrays and key/value pairs - that's about it.

JSON over HTTP doesn't give any type information.

ServiceStack, just like most other RESTful services doing HTTP+JSON, will work just like other services written in other languages - pass JSON back and forth.

Adding IReturn to your service methods will not make your services dependent on ServiceStack - you can use any other HTTP client to make a request and get back JSON in the response.

What is does give you additionally is the option to use a "strongly-typed" http client (JsonServiceClient), which will automatically map to the same .NET type on the client as there is on the server side. So if you want to write a native C#/.NET client for your services, it is incredibly easy.

At the same time, if you or other clients want to write general "untyped" web service clients, those will also work as expected.

Here's how i like to think of it, using ajax client, untyped http+json web service client, and ServiceStack client:

Generic Web Browser:

  • Request (JSON) -> HTTP -> ServiceStack Service
  • Response (JSON) <- HTTP <- ServiceStack Service

Generic HTTP Client:

  • Request (JSON) -> HTTP -> ServiceStack Service
  • Response (JSON) <- HTTP <- ServiceStack Service

ServiceStack's JsonServiceClient:

  • Request (JSON x/.NET type info) -> HTTP -> ServiceStack Service IReturn
  • Response (JSON x/.NET type info) <- HTTP <- ServiceStack Service IReturn

Typically, you would reference the DTO type information from the client and the server project in a *.ServiceModel assembly, which you can use on both ends. Since any type info for DTOs and services are 'in there', the client will know how to deserialize the JSON to the correct type. IReturn is a 'marker' (metadata) on the object - an older SS API used different interfaces to do the same thing, but with more verbosity and less flexibility (different returns for REST vs SOAP it seems).

Also note, your DTOs do not need to implement IReturn - so they do not need to be SS-dependent. I prefer to use IReturn only on "operation" or communication DTOs - those which are passing parameters. I like to keep the DTOs which map to database tables (i.e. - OrmLite) without the IReturn dependency.


share|improve this answer
IReturn<T> is a benign interface which has no affect on any service response (i.e. doesn't add anything to the JSON wire format). It just lets you hold the metadata information about what Response a Request DTO returns saving you from specify it on the call-site each time. –  mythz Sep 15 '13 at 3:37
Thanks for the clarification - i'll fix that. –  Raul Nohea Goodness Sep 15 '13 at 12:02
No need to add strike-thru, answers are a curated knowledge-base that can be edited as many times as you want (ala wikipedia). Feel free to just remove the inaccurate part. –  mythz Sep 15 '13 at 15:59
Thank you for your response. It is much less cloudy to me now ;-) –  Steve Riley Sep 16 '13 at 12:36
add comment

Your Answer


