In my last post, we discovered Routes in ServiceStack. Today let’s go bit further and find out what’s more we could do with routes in ServiceStack. Remember we specified one route for FlightRequest class of our simple Flight Service. That doesn’t mean we are only allowed to add one route per request class in ServiceStack. We may define multiple routes for a selected request and enjoy variety of behaviours. Sounds cool isn’t it? Let’s go ahead and see how to do this.
Here, I am going to add one more route for our FlightRequest class. Since our request object just contains two properties (Departure and Arrival), I am going to define a new route to which, we could directly pass Departure and Arrival parameters instead of passing a populated request object (see below).We are going to use the POST verb for our new route too.
We may still use our first route with a request object that has been populated with Arrival and Departure fields. But, in this example, we are going to use our new route with Arrival and Departure parameters been directly passed into the service URL without using a request object at all.
Now press F5 to start debugging and you would see that our new route is available to use straight away.
Now let’s use this new service URL to invoke a service request via the REST Console tool. Let’s perform an XML request this time. All you need to do is to specify the Departure and Arrival cities within the URL, specify the content type as application/xml and press POST button. You don’t need to worry about the payload as we are not passing a request object this time.
You should be able to get the expected response as shown below.
It is important to take a step back and realise what actually happened here. One important thing to understand is that ServiceStack promotes convention based practice not configuration based practice. Have I done any configuration changes at all to get this behaviour? NO. All I did was specifying a new route with Departure and Arrival parameters built into it. However, when I was defining the new route, I used the exact names of the two properties of the request class.
By doing so, I signaled ServiceStack to use those two URL parameters in place of the actual request object. ServiceStack was smart enough to understand my “notation”, create a FlightRequest object behind the scenes and assign those two parameter values into the Departure and Arrival properties. I can prove my point by placing a breakpoint inside the FlightService operation method and invoking the same service request via the REST Console again!
As you can see, ServiceStack has managed to populate a FlightRequest object using the URL parameters supplied in the route URL.