As a Software developer, I often have to test, explore or script different Web Services. Whether it’s a service I or some of my colleagues work on or it’s a 3d party service we use – doesn’t matter. The reality is that quite often we don’t have a proper client to test the service with, or the client is out of date and doesn’t support some of the interfaces. Whatever the reason is, I quite often ended up using either wget and curl to fire HTTP requests to my services, or using browser-based tools like REST Console (it’s a Google Chrome plugin).
However, using generic HTTP client tools require some tweaking and is a distraction from the main task. On the other hand using REST Console and similar GUI tools is only efficient when you need to test some particular request quickly and just once. If you want to script some tasks or schedule it using cron or just want to prepare some template for repetitive use, those GUI tools have little to offer. There is, of course, another way – to develop a custom command line client specific for your Web Service, but obviously, it’s the most time-consuming approach.
Or, I would say, it was the most time-consuming approach, before we developed Restty.
Restty processes commands in several steps. First step is Template Lookup. Based on restty.profile parameter and first command line argument supplied to the script, it loads appropriate Active JSON template files (_prototype.js is always loaded – it’s used to determine default values).
The next stage is Command Building. During this step input arguments and corresponding values are determined. Then these arguments are made accessible within the template using Context Object $args. And finally, a command is created from the template. All constant values (url, method, …) directly transferred from the template to the command, all functions (body) are executed and the result they returned is assigned to the corresponding field of the command. As the result of this step, we get a command, that contains all the information required to fire an HTTP request towards our Web Service.
Please note, that the arguments may be provided to the command either sequentially, as shown in this example, or as name-value pairs. In the latter case the user input would look like
<strong>my-client put id=10 description="My Item 10 text" name="My Item 10"</strong>
This comes useful when there are more then 2-3 arguments defined for a command. Also, it helps skipping optional arguments.
The next step is Command Execution – using our command object, we perform HTTP request. Returned result we pass to the command for future use.
The last stage is Result Processing (formatting and output). Currently, Restty supports only JSON output format, so the formatting really means that the JSON response is “butified”. The result of formatting then is output to the console.
In the conclusion let me highlight the steps that need to be taken in order to adapt Restty to your specific Web Service:
- Prepare start file (.bat or .sh) with the appropriate meaningful but short name. Place it in the Restty root directory. To keep things simple, use the same name for Restty profile (restty.profile parameter in your start file).
- Create profile directory .\config\profile\[your profile name] or, even better, use one of the provided template directories, just rename it to your profile name. Your profile directory must contain files _config.js – configuration file and _prototype.js - template prototype file.
- In your profile directory, create one template file for each command you want to define. Template file names have to follow this format: [one word command name not starting with "_"].js
We hope, you will find Restty a useful tool and if you do, please, let us know. Also, contact us, if you have some ideas how to improve it or want to contribute to the project.