4 Handling Text Payloads - essenius/FitNesseFitSharpRest GitHub Wiki
Since the payload for a REST service is not prescribed, it can return something else than XML or Json. If the result is not binary, you can use the Text object for those cases. This supports the use of regular expressions to extract values from the payload.
Let’s have a look how that works. We use another REST API from FitNesse, the names responder. This simply returns the names of all the child pages of a page.
!|script |Rest Tester|http://localhost:${Port} |
|Send |Get |to|FitSharpDemos.RestSuite?names|expect code|200|
|$response=|Response Object |
|show |response |
So, the call should provide the names of all child pages of the FitSharpDemos.RestSuite page as the response. It returns this as plain text, each page name on a separate line.
The script table executes the call, puts the response into a text object and shows the raw response.
This is what the result should look like:
!|table: properties for object|$response|!-([a-z|A-Z]*)Test-!|
The table table returns all matches for the regular expression ([a-zA-Z]*)Test
. The value it is looking for is within the parentheses – i.e. a group. It will search for all occurrences of a series of uppercase and/or lowercase letters followed by Test
, and will return those series of letters (i.e. without Test
).
Note the use of !-
and -!
around the regular expression. This is to tell FitNesse not to try and interpret what's in between as Wiki markup, but use it as is.
Notice the Property
column. It contains the regular expression that gives exactly the nth result. That is done by surrounding the provided expression with a non-matching group (otherwise that would be the returned value, and we don’t want that), and then looking for that n times. Also notice that the Value column contains the page name without Test, and the last page is not returned as it does not contain Test
.
You can also use the other tables as described in the Json and XML examples. Even changing and deleting works to some extent.
Now you have had a bird's eye view of the REST fixture, why don't you check out the Reference?