Passing Request DTO to Get() client method without using IReturn

1,191 views
Skip to first unread message

Todd Gleason

unread,
Feb 4, 2013, 1:50:22 PM2/4/13
to servic...@googlegroups.com
I discovered that JsonServiceClient (and probably others) don't let you call Get with just a URL and Request DTO.

If your DTO has IReturn declared, then you can do it, either with a URL or without if the DTO also declares a Route.

You can use Send though, with "GET", the URL, and the DTO. It's very convenient as you can avoid formatting the URL yourself, but it's non-intuitive.

So why not add in a Get<T>() overload that accepts a DTO and avoid using Send() or having to format the URL yourself in C#?

Demis Bellot

unread,
Feb 4, 2013, 2:16:12 PM2/4/13
to servic...@googlegroups.com
Because it only should accept a Request DTO (i.e. not just any object) and the url is formatted according to the rules defined in the [Route] attributes.
The IReturn marker constrains it to a Request DTO. I only want to support Request DTO's with IReturn markers as it encourages the type info to be kept in 1 place (which is inferable by tooling/ServiceStack) as opposed to spreading the type info to all the different call sites.

A "T.Get" method issues a HTTP GET Method that doesn't have a HTTP Request body so all the data on the DTO needs to be transformed into a URL.
This doesn't happen when using a Send/Post (which uses a HTTP POST) or Put methods which have the opportunity to just send the serialized Request DTO into the Request body.





--
You received this message because you are subscribed to the Google Groups "ServiceStack .NET Open Source REST Web Services Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servicestack...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
- Demis

Todd Gleason

unread,
Feb 7, 2013, 5:57:33 PM2/7/13
to servic...@googlegroups.com
On Monday, February 4, 2013 12:16:12 PM UTC-7, mythz wrote:
Because it only should accept a Request DTO (i.e. not just any object) and the url is formatted according to the rules defined in the [Route] attributes.
The IReturn marker constrains it to a Request DTO. I only want to support Request DTO's with IReturn markers as it encourages the type info to be kept in 1 place (which is inferable by tooling/ServiceStack) as opposed to spreading the type info to all the different call sites.

A "T.Get" method issues a HTTP GET Method that doesn't have a HTTP Request body so all the data on the DTO needs to be transformed into a URL.
This doesn't happen when using a Send/Post (which uses a HTTP POST) or Put methods which have the opportunity to just send the serialized Request DTO into the Request body.

Actually, it turns out that Get() cannot take a URL + a request DTO implementing IReturn. So if you are doing custom routing (avoiding using the route parameters due to the separation of concerns issues mentioned in http://stackoverflow.com/questions/12549981/can-servicestack-services-contain-multiple-methods ), you really can't use Get() unless you want to format the URL yourself.

I'm curious whether other people have found that ServiceStack is hard to use without attribute-based routes.

Is Send() with "GET" the best workaround? I'm looking at an extension method along these lines:

        public static TResponse Get<TResponse>(this ServiceClientBase client, string relativeOrAbsoluteUrl, object request)
        {
            return client.Send<TResponse>("GET", relativeOrAbsoluteUrl, request);
        }

(I could also have typed the request to be IReturn<TResponse> instead of object.)

I know that when I get into the service, it has the request filled out, but did it do so in a non-standard way? It looks like ultimately, if you use "GET" or "HEAD", ServiceClientBase.PrepareWebRequest() will serialize the request to a string and append the string to the Uri anyway. So I don't see anything wrong with doing this.

Demis Bellot

unread,
Feb 7, 2013, 6:34:22 PM2/7/13
to servic...@googlegroups.com
Actually, it turns out that Get() cannot take a URL + a request DTO implementing IReturn. 

These are the 2 calling patterns that you can have when you implement IReturn*:

    List<Customer> customers = client.Get(new SearchCustomers { City = "NY" });

or

    List<Customer> customers = client.Get<List<Customer>>("customers?City=NY");

If you didn't implement IReturn* you can only do the latter.

you really can't use Get() unless you want to format the URL yourself.

If you don't want to implement IReturn* then you need to specify the "GET Url" used, if you implement IReturn* you can have typed access and you don't even need to specify any [Route] attributes since the client will fallback to use the pre-defined routes.

I'm curious whether other people have found that ServiceStack is hard to use without attribute-based routes.

Not sure why it matters, use them if you want pretty customized routes, or don't use them and it will fallback to using the pre-defined routes.

Is Send() with "GET" the best workaround? I'm looking at an extension method along these lines..

Sure, tho like I said earlier we want to encourage people to implement the `IReturn` marker which keeps the return type info for the Request DTO in 1 place (rather than repeated in all the different call-sites), that's statically inferable by tooling and verifiable by the compiler.

I know that when I get into the service, it has the request filled out, but did it do so in a non-standard way? It looks like ultimately, if you use "GET" or "HEAD", ServiceClientBase.PrepareWebRequest() will serialize the request to a string and append the string to the Uri anyway. So I don't see anything wrong with doing this.

Not sure what's being asked here.



--
You received this message because you are subscribed to the Google Groups "ServiceStack .NET Open Source REST Web Services Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servicestack...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply all
Reply to author
Forward
0 new messages