Interestingly, the side chat for DotNetConf contained a brief conversation about Fiddler vs. Postman. Most folks were fond of Postman and preferred it over Fiddler for basic HTTP calls because of its refined and smooth interface (in fact I think these were the paraphrased sentiments of Scott Hanselman in the conversation). While Postman is not by any means a replacement for the rich feature functionality of Fiddler, it certainly has a bit more polished UI and easier to use for constructing basic GET and POST calls. If you are not doing any special debugging, I would probably use Postman 1st and Fiddler in other scenarios.
The main features I like about Postman are the following:
- History of calls down the left-hand pane for easy access to recall recent GET, POST, etc.
- Ability to add in Basic Authentication Headers in their raw form without having to Base64 encode them 1st (Postman will do this for you)
- Simplicity to add custom headers
- Ability to have the URL contain spaces instead of having to encode the query string with %20. This is key for creating OData calls using OData commands.
- Smooth, refined, easy to use interface
Below are the security option tabs across the top of the product. Often you will use 'Normal' or 'Basic Auth'. Normal would be used if you are not adding any authentication information to the headers.
Basic Auth is used when adding HTTP Basic Authentication information to the request headers. As you can see you can enter in the credentials directly without having to encode the information manually:
Once you press the 'Refresh headers' button, the encoded basic authentication information will be added for you! Saves a bit of time as opposed to having to do this through a site, test harness, or code.
You can also easily add custom headers by simply typing in he 'Header' and 'Value' text boxes and again pressing the 'Refresh headers' button. It's nice and organized and makes sure the headers are added properly to the request and reduces chances you might add the header values incorrectly.
As far as using OData command parameter, notice in my query string how I do not have to encode the 'spaces' in the URL. The tool will construct and encode the URL for me, making writing OData queries much easier. You can add the commands directly to the URL or type them in the 'URL Parameter Key' and 'Value' text boxes:
One other nicety to mention is if constructing a traditional query string parameter, you can add those parameters easily too, and Postman will make sure the query string is constructed properly.
This was just a brief introduction to Postman, but I highly recommend it's usage for OData service calls or any other REST based calls. It makes constructing OData queries easier, and its user friendly interface is a great choice for traditional REST based calls.
Thanks for the detail, how can we parameterize the end point url, i.e i need to run existing test cases against environment without changing the end point url manually.
ReplyDelete