smartrics/RestFixture — Issue #8: RestFixture requiring a base URL - any way to avoid that?
Author: lachelt
Created: 2012-02-01 17:19:27+00:00
State: open

This isn't really an issue... more of an observation and question.

RestFixture requires a base URL to be supplied. However, our resources tend to contain fields which are URI references to other resources. Those URIs are complete URIs which we shouldn't have to introspect. In our testing, we want to be able to GET a resource and then pull the references out of the fields and then use those URIs in subsequent GETs. But the RestFixture won't let us use those URIs because they are complete URIs... and it just tries to append the URI onto the base URL specified when the fixture is declared:

Here's an example:

Now we get a specific account from the collection
!|smartrics.rest.fitnesse.fixture.RestFixture|http://${HOST_PORT}|
|GET|/account?lastName=Bourne|200||jsonbody[0].resource.emailAddr=="json.bourne@hp.com"|
|let|acctref|js|response.jsonbody[0].uri||

Now we try to delete the account
!|smartrics.rest.fitnesse.fixture.RestFixture||
|DELETE|%acctref%|200|||

The GET returns this collection of resources:

[{"resource":{"emailAddr":"json.bourne@hp.com","firstName":"Json","lastName":"Bourne"},"uri":"http://redpoint:8111/account/4f2970bbe4b01ea02233c343"}]

The DELETE as declared here doesn't work obviously because the RestFixture requires a base URL. But if we specify a base URL (say http://redpoint:8111) then the %acctRef% which we got in the previous GET won't work because the fixture attempts to append it to the base.

We are defining our resources in what we think is a normal fashion (similar to examples in the RESTful Web Services Cookbook, and other text about RESTful services. It seems as if your RestFixture was crafted for a specific style of resource definitions where any embedded resource references would not contain the "base" portion of the URI.

We're happy to enhance the RestFixture code to be useful in our situation, but I wonder if you have some suggestion for how to use the current implementation that we are missing.