The above solution contains the implementation of the GetDirectoryInfo web service. The GetDirectoryInfo.cs class contains the contract of the service i.e. What it accepts (Request DTO) and what it returns (Response DTO).
Although not required, it is a good idea to keep the definition of your 'web services' separate from your implementation as it will allow you to share this assembly with your .NET clients.
As can be seen from the Example code, defining your web service definition is simply done with POCO DataContract classes. ServiceStack doesn't impose any enforced structure or interfaces which means that you have complete control of the definition of your web service, including its XML namespaces.
A convention that ServiceStack does use is that the name of your Response DTO should be:
[Name of Request DTO] + 'Response'. Which in this case would be 'GetDirectoryInfoResponse'.
For completeness I've included the other DataContract's used by this service below:
So a pretty simple service, from the DTO's we can tell our GetDirectoryInfo Web Service:
For lack of a better idea, the GetDirectoryInfo service actually sends back info about itself, (i.e. It allows you view the entire file/directory structure of the RemoteInfo solution). You can of course change the root Directory it looks at in the Application .config file (i.e. Web.Config).
The only thing remaining to make this web service work is the actual implementation :) which I've included below:
So there a couple of things going here. The first is to tell ServiceStack which Web Service we are implementing. This is done by specifying the type of Request DTO in the IService<> interface.
The constructor for your handler should either be empty or containing members of providers you've registered in your AppHost.cs file. Public properties are also auto-wired to receive configured dependencies as well.
The IService has one method which is object Execute(TRequest)
Quite simply ServiceStack calls your service passing in the request as a strongly-typed RequestDto.
To complete the request you just need to return the Web Services Response DTO, which in this case is
an instance of GetDirectoryInfoResponse.
That's all there is to it! If you start XSP again you can now call this Web Service via REST using the following url:
Calling the REST service with arguments is done by adding Key/Value pairs to QueryString that the Web Service expects. Since the Web Service displays information about itself you can view the contents of the directory where the handler is using the following url:
Assuming you have no problems, navigating to that url from a browser with a decent XML renderer (for me thats Firefox on OSX) should give you:
A REST-full Web Service, Cool!
Next step is to call the Web Service from inside a .NET application.
Before we attempt to call this service from MonoTouch, it is a good idea to test calling the Web Service from
a standard .NET Console Application as it will help you identify whether any errors are Web Service or MonoTouch related.
The RemoteInfo.Tests.ConsoleClient does exactly this, it lets you call the GetDirectoryInfo Web Service with JSON or XML using either the XSP or Console Host. The easiest way to get this running is to set RemoteInfo.Tests.ConsoleClient as your 'Startup Project' and hit 'Debug', if all is good should expect to see:
You can run the ConsoleClient with different arguments to change the Web Service Host (i.e. Web Host or Console Host) or End Point (i.e. XML or JSON) you want to call. Regardless of the combination you use, the 'client code' to call and access the Response remains the same as can be seen onwards from Line 58.