How the Other Half Lives
I wrote an article here entitled "Use a Generic Util for Easily Testing REST Methods" that makes testing REST methods easy provided you
incorporate the args passed via the URI into the server's routing attributes.
IOW, with Controller method routing attributes such as this:
[Route("api/DeliveryItems/{serialNum}/{ID:int}/{CountToFetch:int}")]
...the client accesses the method annotated in that way with a URI such as:
http:
Or for a literal/specific example:
http:
This works fine and has the advantage of making the routing attribute on the server self-documenting. However, it does mix path/routing
information (the "http://<serverName>:<portNum>/api/<ControllerName>" part) with args to be passed to the method (the
"<serialNumVal>/<IDVal>/<CountToFetchVal>" part).
Therefore, I have created a new utility which allows for testing of methods that have routing attributes instead like this:
[Route("api/DeliveryItems")]
The method itself remains the same:
public IEnumerable<deliveryitem> GetRangeOfDeliveryItemsByStartingID(string serialNum, int ID, int CountToFetch)
{
return _deliveryItemRepository.GetRange(string serialNum, ID, CountToFetch);
}
...but now it is called by the client this way:
http:
<arg1Name>=<arg1Val>&<arg2Name>=<arg2Val> (etc.)
A literal example is:
http:
-or, if there is a "differentiator" (name of a method to overcome any possible ambiguity):
http:
Usage of the Util
To use the new Web API REST Tester utility, first you need to either save to file or add to the "Select a URI String" combo box entries in this format:
- deliveries/Count
- deliveries/GetAll
- deliveries?ID={0}
- deliveries?ID={0}&CountToFetch={1}
- departments?serialNum={0}&ID={1}&CountToFetch={2}
- InventoryItems?serialNum={0}&ID={1}&CountToFetch={2}&packSize={3}
- InventoryItems/GetDeptRange?serialNum={0}&BeginDept={1}&EndDept={2}
IOW, Controller name, followed by Differentiator if there is one (such as "Count" or "GetAll"), followed by a question mark for the first arg,
name of arg, equals sign, and "{0}". For subsequent args, an ampersand replaces the question mark and the number within the curly braces is
incremented. The util will replace these "curly brace sandwich numbers" with values you add later.
Then, follow these steps (the step numbers correspond to what you see on the form):
0) Enter the "base uri" in the "Enter Base URI" textbox. This is something like "http://localhost:28642/api/"
1) if you saved the values to a text file, you can load it via the "Load URI Strings From File" button.
2) Select a value from the combo box.
3) Mash the "3) Discover URI Strings Args" button. This will visiblize a corresponding label and textbox where you can enter the value you
want to use for each arg.
4) Enter values for each arg discovered:
5) Mash the "5) (Re)Build URI" button. It will build the URI to be passed to the server, replacing the placeholder vals with the values you
entered in the text boxes, and displaying that in the textbox to the right of the "5) (Re)Build URI" button:
6) With the server running, as the Coup de grâce, mash the "6) Test the URI" button. If your code is right and the poles have not suddenly
reversed and there was no giant electromagnetic storm, you will see the results displayed in the DataGridView below.
Note: The larger file is the entire project saved from Visual Studio via File > Export Template... The smaller file is the source code in a text file.
Subtle Hints, Supple Hands, and Desired Mints
If you like this article, take note that I am registered at Tiffany's (I have even breakfasted there on occasion!), and I've always wanted to "bling out," preferably with rubies, diamonds, sapphires, and lapis lazuli, not to mention scads of cubic zirconium. Just sayin'
