0

I am using the protobuf addin and I basically have the exact same set up as the examples (I just renamed things to represent my domain better and added some properties to the DTO's).

I have created the service successfully. It runs and returns correct data when I invoke the webservice using: htp://myserver:port/Account/02345432?format=x-protobuf

However when I try to programmatically connect to the service in the following way:

var client = new ProtoBufServiceClient("htp://myserver:port");
var request = new GetAccount
                      {
                          AccountNumber = "02345432"
                      };

var result = client.Send<GetAccountResponse>("GET", "/Account", request);

I receive an exception "Handler for Request not found"

What I have noticed in the body of the exception response is that the URL it is trying to access is: htp://myserver:port/Account?AccountNumber=02345432

(and yes, I used htp on purpose to avoid the link ban)

Obviously I'm missing something. Can someone point me to the error of my ways?


Edit 1

@stefan I also read the "Winning with Rest & ProtoBuf" and I essentially have implemented exactly what that article has done. The problem is the article never gets around to showing how to consume the webservice with the ProtoBufServiceClient. I get to exactly the same place as the article does (my webservice returns the saved binary file with the correct data in it when browsing the correct url). When I try your suggestion to do client.Get<..>("/Account/02345432") I get a different exception: Invalid wire-type;


Edit 2

I discovered the error, unfortunately nothing exciting: PEBKAC. I neglected to wrap my returned data in my ResponseDTO, so really the "Invalid wire-type" should have clued me in. It was not until I started doing a line by line comparison that I discovered this. So yes service stack was doing the best it could with my lack of precision by serializing the unexpected object and returning it. Unfortunately, the client on the other end is expecting an AccountResponse DTO, not a raw Account.

Bitfiddler
  • 3,942
  • 7
  • 36
  • 51
  • Maybe these questions [Protobuf-net... an unknown wire-type](http://stackoverflow.com/questions/2152978/using-protobuf-net-i-suddenly-got-an-exception-about-an-unknown-wire-type) or [getting-servicestack-to-retain-type-information](http://stackoverflow.com/questions/10750571/getting-servicestack-to-retain-type-information) can help you ? Where is your DTO ? do you use inheritance ? – stefan2410 Sep 23 '13 at 17:15

1 Answers1

1

Maybe somebody else, can answer better this question, but I will try also to answer it.

The documentation in the ServiceStack C# Client describes that for the REST API
we use the client.Get or client.Post.

If you read the code in the ServiceStack tests,( projects ServiceStack.WebHost.Endpoints.Tests, ServiceStack.WebHost.IntegrationTests ) you will see some examples

like

     var response = client.Get<MoviesResponse>("/cached/movies"); 
    //  or    
      var response = client.Post<ProtoBufEmail>(  "/cached/protobuf",
                           new UncachedProtoBufEmail {
                                      FromAddress = fromEmail
                                       });
     // or using the Send without Rest method
                var response = client.Send<ProtoBufEmail>(request);

You can read also a helpful post about #WINNING with C# ServiceStack: REST with ProtoBuf

I am not sure, if using the Get or the Post, will solve your problem.

The error "Handler for Request not found" maybe it is related with your Routes.

As you wrote, you could invoke the web-service successfully using the Uri "/Account/02345432"

Your Get method, should be

          var result = client.Get<GetAccountResponse>("/Account/02345432");

maybe this Designing a REST-ful service with ServiceStack is helpful also.

Community
  • 1
  • 1
stefan2410
  • 1,931
  • 2
  • 16
  • 21
  • Isn't that what the client should be doing? As in, formatting the request appropriate for the server? I mean, what's the point of the DTO if I'm hand crafting the URL? – Bitfiddler Sep 23 '13 at 14:35
  • maybe this question is helpful [Purpose of IReturn and IReturnVoid within JsonServiceClient.Get](http://stackoverflow.com/questions/18802699/purpose-of-ireturn-and-ireturnvoid-within-jsonserviceclient-get) If you mark the DTO with the IReturn, the Get will craft the DTO. there is also an [auto mapping](http://stackoverflow.com/questions/15368257/servicestack-new-service-side-by-side-asp-net-mvc-website/15369736#15369736) Otherwise with a simple C# object, – stefan2410 Sep 23 '13 at 17:27
  • I prefer using a C# object to avoid dependencies(even a marker interface like IReturn), I'm hand crafting the URL, or I use Post like GetRequest. In RESTful model, the URI in Get should include the resource unique indetifier. – stefan2410 Sep 23 '13 at 17:35
  • @Stephan, thanks for all your input. Unfortunately the problem was much less exciting (see above). Fortunately, servicestack does perform as expected (you don't need to craft your URL's by hand). When you set everything up right you can just point your client to the base url of your service, new up a request DTO and send it. Service stack automagically maps the request object to the right URL and passes the AccountNumber as a parameter. – Bitfiddler Sep 23 '13 at 18:06
  • @Stephan, also what I have done is to put the request/response DTO's in a seperate assembly and included it in my service. I can then package up this other assembly (which I call ServiceModels) as a nuget package and include it in all my clients. I avoid having to do any extra work with URLs or proxy generation that way. – Bitfiddler Sep 23 '13 at 18:08
  • @BitFiddler, glad you solve your problem. Yes the request/response DTO's as in the Service Model as you did. Yes using IReturn and Get, you will have the auto mapping. My remark was only that I prefer not having dependencies. Also I have mainly Jquery Ajax clients, not only C#. I prefer also not using Send in a REST API. The uri "/Account" for a GET operation has not any resource unique identifier, as it should be in RESTFul model. – stefan2410 Sep 23 '13 at 18:16