Hi William,
> One of the things I like about the Restlet approach is that request
> routing is a separable piece of logic, rather than something
> mysterious that happens based on an XML file.
Thanks for the feed-back on this rarely discussed aspect of the API.
> One of the many nice things about that is that it's testable.
> However, my
> test is looking a little weird, and I wondered if I was going
> about things
> the wrong way.
OK
> Suppose I start out with a Router that has just one path,
> "/", which maps
> to my HomePageRestlet. After some fiddling, the passing test
> I ended up with is like this:
>
> @Test
> public void testHomePage() {
> Router router = new MyRouter();
> Request request = new Request(Method.GET, new Reference(new
> Reference("http://example.com";),"http://example.com/";));
> Route restlet = (Route) router.getNext(request, new
> Response(request));
> assertThat(restlet.getNext(),is(HomePageRestlet.class));
> }
>
> However, I was expecting that request construction line to
> look more like
> this:
>
> Request request = new Request(Method.GET,
> "http://example.com/";);
>
> Or I could squeak by with this, but is it kosher?
>
> Request request = new Request(Method.GET, "/");
The routing assumes that your request contains an absolute target URI that
identifies a target resource. During the routing process the resource's base
URI is continuously updated to implement a hierarchical URI routing
approach, as described here:
http://www.restlet.org/documentation/1.1/tutorial#part11
> Turning to the last two lines, they look funny to me with that cast.
> Ideally I'd like something more like
>
> Restlet restlet = router.getNext(request, new
> Response(request));
> assertThat(restlet, is(HomePageRestlet.class));
>
> Or even
>
> assertThat(router.route(request), is(HomePageRestlet.class));
We could have directly linked target Restlets/Resources to the Router but
the concept of Route was formalized to add features such as route scoring
and filtering.
> I could of course hide the extra stuff in a helper method,
> but before I do
> that I thought I'd see if I was missing a better way to write
> the tests.
If you want to test the routing logic per-se, and not just test the outcome
of the processing of routed requests, it seems like your approach is fine.
Please continue to give us feed-back along the road. This is an interesting
use case for the API.
Best regards,
Jerome
